# TSRMLS_D/C persistence

- Thread: https://externals.io/message/24232
- Original archive: https://news-web.php.net/php.internals/24232
- Started by Andrew MatherBt on 2006-06-30T22:54:02+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #24232 — Andrew MatherBt — 2006-06-30T22:54:02+00:00

URL: https://externals.io/message/24232#24232

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.

---

## #24233 — l0t3k — 2006-06-30T23:24:54+00:00

URL: https://externals.io/message/24232#24233 · In reply to: #24232

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.

---

## #24234 — Sara Golemon — 2006-07-01T01:18:02+00:00

URL: https://externals.io/message/24232#24234 · In reply to: #24232

> 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

---

## #24239 — Sara Golemon — 2006-07-01T16:49:13+00:00

URL: https://externals.io/message/24232#24239

> 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