At the risk of inflaming an already tense conversation (too late), I have to say that third party thread-safety issues are not a very good excuse.
It's trivial to make a library thread safe by serializing access to the functions of the non-thread-safe library. Although scripts that employ the non-thread-safe library would suffer a performance penalty, they would still work! If the core of PHP is thread safe, then this should not be a big deal. Also, as time goes on, third party library locks can be removed as thread-safe versions of the libraries become available. For a well-written and concise explanation, please refer to: http://www.unet.univie.ac.at/aix/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm Cheers, -Glenn On Fri, Feb 07, 2003 at 02:02:39AM +0100, Sascha Schumann wrote: > > Rather than fix the TS issues in all the 3rd party libraries > > that can be used with PHP's and its extension its more > > pragmatic to sort out thread/filter issues in PHP core. > > The PHP project has been working on thread-safety since 1999. > All core components and most extensions can be compiled in > thread-safe mode. > > The first SAPI module for a threaded UNIX web server was > completed in the same year (for AOLserver). > > It's safe to assert that we need to primarily worry about 3rd > party libraries. > > > Also blaming on use of TLS seems a little strange since use of > > TLS is supposed to improve re-entrancy isn't it ? > > Let me just quickly define what these concepts refer to. > > Thread-safe means that you can run code in multiple threads > concurrently (e.g. multiple worker threads). > > Reentrant means that you can run code in a single thread > context in a nested way (e.g. Apache sub-requests). > > Thread local storage aids only the former one. > > From my point of view we should not worry about reentrancy > right now, at least not until we a have firm grasp on the 3rd > party TS issues. > > - Sascha
