> Hi Pierre,
>
>
>> slow (as you noticed). However it can't be done in 5.3 as it will
>> break the ABI.
>>
>
> I noticed that a recent fix (http://bugs.php.net/bug.php?id=49936)
> added TSRMLS_DC to an API in 5.3.
> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/streams/php_stream_context.h?r1=290796&r2=290795&pathrev=290796
>
> Wouldn't that need to be reverted as it breaks the ABI?
>

How about the idea below:
you can introduce new functions/macros with TSRMLSx propagated in, in v5.3 
without changing existing API exposed to extensions, and make core using new 
API.
Old functions/macros can be marked as deprecated. This will preseve ABI in 
v5.3 :)
As of v6, you don't have to preserve ABI, so you can do replace the 
functions with new ones at once (introduce new, remove old, get all parts 
using new).
Hmm and the diff will be big...

BTW, did you try to avoid pthread_get_specific() calls now and forever? 
Something like just one pointer in static TLS would do.
http://people.redhat.com/drepper/tls.pdf
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html
Since static TLS storage is quite a limited resource under some OSes, I 
think it will be wise to use only one thread-specific pointer in TLS and 
this pointer will point to the thread-specific array of pointers (not in TLS 
but in regular heap) and these pointers will point to all thread-globals 
like CG(), EG(), etc. The index of the array will be well-known id returned 
by ts_allocate_id.
These arrays should be big enough to allow new globals to be added in 
run-time without re-allocating all the arrays in all currently running 
threads (see how ts_allocate_id() extends the arrays with pointers one by 
one, locking all threads).
Structure and dereferencing  will be exactly the same as currently 
implemented in TSRM.h, only storage will be declared global with __thread 
prefix and all related calls like TlsAlloc(), pthread_key_create would be 
removed.

-jv



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to