Do you really think we don't know this? The point is that at this point we would basically have to mutex every call to every 3rd-party library function since we simply don't know which ones are threadsafe and which ones aren't. And if we lock everything, isn't it simpler to just go prefork and avoid the whole thing?
It boils down to where our time is best spent. Yes, we can come up with all sorts of tricks to sorta-kinda-almost make this work. But why? What do we gain? At this point most of us feel that we really don't gain anything. -Rasmus On Sun, 9 Feb 2003, Glenn wrote: > 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 >
