Re: TSRMLS_D/C persistence

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.