TSRMLS_D/C persistence

20 years ago by Andrew MatherBt — view source — reply

unread

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.

20 years ago by l0t3k — view source — reply

unread

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.

20 years ago by Sara Golemon — view source — reply

unread

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

20 years ago by Sara Golemon — view source — reply

unread

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

TSRMLS_D/C persistence View as Markdown