FAQ
I've written an extension which needs to accept a Resource which is an SQLite
database handle, and call a C function which will be using that db handle to
issue queries. What I've done works, but is kinda nasty because there doesn't
appear to be a clean way to obtain that database handle nor, from what I can
tell, determine the resource type to expect. Is there a nicer way of doing
this?

PHP_FUNCTION(my_PHP_function)
{
int id;
int dataLen;
int resourceType;
char * pData;
zval * zdb;
void * hDB;
void ** phDB;

/* Ensure we got the correct number of parameters */
if (ZEND_NUM_ARGS() != 2)
{
WRONG_PARAM_COUNT;
}

/* Retrieve the parameters */
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
"rs",
&zdb, &pData, &dataLen) == FAILURE)
{
return;
}

/*
* Voodoo to retrieve the sqlite database handle from the resource.
* How do I validate that resourceType is reasonable?
*/
id = zdb->value.lval;
if ((phDB = zend_list_find(id, &resourceType)) == NULL)
{
return;
}

/*
* This is nasty too. We "know" that the first field in the private
* structure is the database handle. Just extract it.
*/
hDB = *phDB;

RETURN_STRING(my_C_function(hDB, pData), TRUE);
}


Thanks,

Derrell

Search Discussions

  • Wez Furlong at Feb 4, 2005 at 1:37 am
    There is no official way to do this kind of thing between arbitrary extensions.
    When extensions that are written to share this information, they
    typically export an XXX_API function that you can link against to
    fetch the data.

    What you've done works, so that's fine, although there is a risk of
    crashing if someone passes the wrong type of resource in. If you're
    thinking of distributing your extension, we could add a more official
    API for you to use, although that doesn't exist in older versions of
    the extension, etc. etc.

    Some time back, I proposed a framework (and even a patch IIRC) that
    allowed this kind of thing at run-time; despite "we the extension
    developers" liking the idea, there was some negative feedback from
    andi/zeev so it never went further. Search the php-dev archives for
    my name and "interfaces" for more on that if you're interesting in
    this seeing light in PHP 5.2.

    --Wez.

    On Thu, 03 Feb 2005 17:03:45 -0500, Derrell.Lipman@unwireduniverse.com
    wrote:
    I've written an extension which needs to accept a Resource which is an SQLite
    database handle, and call a C function which will be using that db handle to
    issue queries. What I've done works, but is kinda nasty because there doesn't
    appear to be a clean way to obtain that database handle nor, from what I can
    tell, determine the resource type to expect. Is there a nicer way of doing
    this?

    PHP_FUNCTION(my_PHP_function)
    {
    int id;
    int dataLen;
    int resourceType;
    char * pData;
    zval * zdb;
    void * hDB;
    void ** phDB;

    /* Ensure we got the correct number of parameters */
    if (ZEND_NUM_ARGS() != 2)
    {
    WRONG_PARAM_COUNT;
    }

    /* Retrieve the parameters */
    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
    "rs",
    &zdb, &pData, &dataLen) == FAILURE)
    {
    return;
    }

    /*
    * Voodoo to retrieve the sqlite database handle from the resource.
    * How do I validate that resourceType is reasonable?
    */
    id = zdb->value.lval;
    if ((phDB = zend_list_find(id, &resourceType)) == NULL)
    {
    return;
    }

    /*
    * This is nasty too. We "know" that the first field in the private
    * structure is the database handle. Just extract it.
    */
    hDB = *phDB;

    RETURN_STRING(my_C_function(hDB, pData), TRUE);
    }

    Thanks,

    Derrell

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derrell Lipman at Feb 4, 2005 at 4:19 am

    Wez Furlong writes:

    There is no official way to do this kind of thing between arbitrary
    extensions. When extensions that are written to share this information,
    they typically export an XXX_API function that you can link against to fetch
    the data.

    What you've done works, so that's fine, although there is a risk of
    crashing if someone passes the wrong type of resource in. If you're
    thinking of distributing your extension, we could add a more official
    API for you to use, although that doesn't exist in older versions of
    the extension, etc. etc.
    Thanks, Wez. My extension will likely never be used other than with
    locally-written code. My biggest concern is making use of the incestual
    knowledge of the private php_sqlite_db structure and that the database handle
    is the first field in it. That structure may change in the future.

    My use of this is as a function used in a query -- sqlite_create_function() is
    used to allow a call to a php function which passes the database handle to the
    extension function. Prior to today, my extension had its own private database
    handle that it initialized on the MINIT function, but I was causing a deadlock
    by calling this function from within a query in PHP which called the extension
    which tried to issue additional queries using my private database handle in
    the extension. Passing in the php-derived handle is the only way of
    eliminating that deadlock.

    I wonder whether I'm really alone in wanting access to a database handle for
    extensions. It would seem appropriate to provide access to the C-level
    database handle given a PHP resources. That would eliminate the need to base
    an extenion on insestual knowledge of the database-specific extension.

    Thanks again,

    Derrell
  • Andrei Zmievski at Feb 4, 2005 at 9:40 pm

    On Thu, 03 Feb 2005, Wez Furlong wrote:
    Some time back, I proposed a framework (and even a patch IIRC) that
    allowed this kind of thing at run-time; despite "we the extension
    developers" liking the idea, there was some negative feedback from
    andi/zeev so it never went further. Search the php-dev archives for
    my name and "interfaces" for more on that if you're interesting in
    this seeing light in PHP 5.2.
    I'd definitely be interested in seeing the extension dependency
    framework in 5.2.

    - Andrei
  • Rasmus Lerdorf at Feb 4, 2005 at 9:46 pm

    Andrei Zmievski wrote:
    On Thu, 03 Feb 2005, Wez Furlong wrote:

    Some time back, I proposed a framework (and even a patch IIRC) that
    allowed this kind of thing at run-time; despite "we the extension
    developers" liking the idea, there was some negative feedback from
    andi/zeev so it never went further. Search the php-dev archives for
    my name and "interfaces" for more on that if you're interesting in
    this seeing light in PHP 5.2.

    I'd definitely be interested in seeing the extension dependency
    framework in 5.2.
    We need it for the ext/libxml mess, for example.

    -Rasmus
  • Wez Furlong at Feb 4, 2005 at 9:51 pm
    The extension deps framework (that orders the initialization done in
    internal_functions.c) is already in HEAD; I was talking about the
    extension "interfaces" idea I proposed a fairly long time ago now
    (long enough that I can't remember how long ago). I remember you
    showing interest in that at that time.

    --Wez.
    I'd definitely be interested in seeing the extension dependency
    framework in 5.2.

    - Andrei
  • L0t3k at Feb 4, 2005 at 11:12 pm
    i found this

    http://www.zend.com/lists/php-dev/200204/msg01083.html



    "Wez Furlong" <kingwez@gmail.com> wrote in message
    news:4e89b42605020413515e6448e6@mail.gmail.com...
    The extension deps framework (that orders the initialization done in
    internal_functions.c) is already in HEAD; I was talking about the
    extension "interfaces" idea I proposed a fairly long time ago now
    (long enough that I can't remember how long ago). I remember you
    showing interest in that at that time.

    --Wez.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 3, '05 at 10:03p
activeFeb 4, '05 at 11:12p
posts7
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase