Re: [PATCH] - Improving multi-threaded performance by propagating TSRMLS_C

> 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