FAQ
How long are the TSRMLS_D/C parameters good for?

Can the resultant tsrm_ls value be safely stored?

I presume the answer is no, and these paramters
should be passed in each time a function is called,
but I would be curious to know differently, if for example
it could be passed in once at (external object) creation time,
and that object could use the trsm_ls directly, rather than the
TSRMLS_D/C semantics.

...

Otherwise it seems clear that an external object outside php
cannot use php semantics, so cannot use the php_stream wrappers.

...

That being the case, an external object (referenced from within eg:
a php extension) must either:

a. be able to ignore php-streams and use system streams directly
(not obviously apparent, given errors experienced to date)
or

b. cannot use system streams when calls originate from php/extensions,
(in which case no 3rd party objects which access streams are reliable in
php/extensions)

Clearly a. is more desirable than b. , despite the fact that an apparently
reliable 3rd party object did generate errors when called from within a
php-extension.

---

This is my third attempt to ask for a clear answer as to whether a. or b.
is correct, so hopefully someone will notice, has the answer, and can respond.

Cheers,

Andrew.

Search Discussions

  • L0t3k at Jun 30, 2006 at 11:47 pm
    Andrew,
    i've only skimmed your question, and at the risk of being irrelevant ...

    check out

    http://cvs.php.net/viewvc.cgi/php-src/ext/unicode/property.c?revision=1.14&view=markup

    and search for PHP_FUNCTION(char_enum_names).

    Pay attention to the macro
    TSRMLS_SET_CTX(ectx.thread_ctx)in that function, and the macro
    TSRMLS_FETCH_FROM_CTX(ctx->thread_ctx);in the callback
    php_enum_char_type_range()l0t3k


    ""Andrew MatherBt"" <an.dromeda@btconnect.com> wrote in message
    news:200606302354.02272.an.dromeda@btconnect.com...
    How long are the TSRMLS_D/C parameters good for?

    Can the resultant tsrm_ls value be safely stored?

    I presume the answer is no, and these paramters
    should be passed in each time a function is called,
    but I would be curious to know differently, if for example
    it could be passed in once at (external object) creation time,
    and that object could use the trsm_ls directly, rather than the
    TSRMLS_D/C semantics.

    ...

    Otherwise it seems clear that an external object outside php
    cannot use php semantics, so cannot use the php_stream wrappers.

    ...

    That being the case, an external object (referenced from within eg:
    a php extension) must either:

    a. be able to ignore php-streams and use system streams directly
    (not obviously apparent, given errors experienced to date)
    or

    b. cannot use system streams when calls originate from php/extensions,
    (in which case no 3rd party objects which access streams are reliable in
    php/extensions)

    Clearly a. is more desirable than b. , despite the fact that an apparently
    reliable 3rd party object did generate errors when called from within a
    php-extension.

    ---

    This is my third attempt to ask for a clear answer as to whether a. or b.
    is correct, so hopefully someone will notice, has the answer, and can
    respond.

    Cheers,

    Andrew.
  • Sara Golemon at Jul 1, 2006 at 1:38 am

    How long are the TSRMLS_D/C parameters good for?
    The life of a given thread.
    Can the resultant tsrm_ls value be safely stored?
    Yes, but only during the life of a thread. For practical purposes, you
    should consider this to mean the life of a request since there is no
    guarantee that subsequent requests will be serviced by the same thread.
    I presume the answer is no, and these paramters
    should be passed in each time a function is called,
    but I would be curious to know differently, if for example
    it could be passed in once at (external object) creation time,
    and that object could use the trsm_ls directly, rather than the
    TSRMLS_D/C semantics.
    Yes, and I've done that on more than one occasion.

    A given tsrm_ls value is tied to a thread (and uniquely identifies that
    thread). Since a given request never jumps from one thread to another (It
    stays in the thread it was born in), the tsrm_ls you get at one point in a
    request will be the tsrm_ls you get at another point in a request.

    -Sara
    http://blog.libssh2.org/index.php?/archives/22-What-the-heck-is-TSRMLS_CC-anyway.html
  • Sara Golemon at Jul 1, 2006 at 4:49 pm

    That also implies then that if I create a handler for eg: an
    external stream/file, and keep it as a singleton instance in the
    extension, then it could be reasonably called by any number
    of different threads.
    There's a plan B though.

    void foo(int bar) { }

    foo() doesn't have room for trms_ls in its prototype so it just won't be
    available inside the function right? Wrong. Zend exports TSRMLS_FETCH();
    which can recover (through a slightly expensive process) the thread
    appropriate value for tsrm_ls. Thus:

    void foo(int bar TSRMLS_DC)
    {
    somefoo(bar TSRMLS_CC);
    }

    and

    void foo(int bar)
    {
    TSRMLS_FETCH();

    somefoo(bar TSRMLS_CC);
    }

    Are functionally identical.
    ie: any resource callable from a php-extension must be
    thread safe...
    In order to work in all build environments? Yes.
    Would that be a fair comment? (Means my single-threaded
    data engine prototype is going to need a serious going over).
    Technically, if you *know* that your php-extension will only ever be used in
    a non-threaded environment (e.g. non-Win32, non-Apache2,
    non-otherThreadedWebSAPI), then you can be "lazy" and not worry about thread
    safety (or tsrm_ls in general). I would however *strongly recommend*
    reworking your library for thread safety so that this problem doesn't become
    an issue later on.

    -Sara

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJun 30, '06 at 10:54p
activeJul 1, '06 at 4:49p
posts4
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase