>> No. Php if we talk about php with all its extensions is not threadsafe >> at >> all. Many of the extensions allocate static data and inherently >> non-thread-safe. > > PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by > some extensions might not be thread safe, but basically all "usually" > used ones are thread-safe. While it is a bit complicated as some > libraries could either be compiled thread-safe or not or some might be > not thread-safe on specific systems ... but that's not PHP itself ;-) > > johannes >
Dear Johannes, I'm not sure why you repeated what I stated in my post. So I'm repeating it after you too :) Yes, php core is developed with threadsafe techniques in mind, some extensions are safe too, and some extensions which are using 3rd party libraries are definitely not safe. The only thing I'd kindly ask you to pay more attention to is using "usually" word together with "safe" in one sentence. In my opinion they should never be used both if we talk about production servers, or at least servers where crashes are not welcome. Just to illustrate the issue with "usually", do you consider openssl, a widely used php extension, as a "usually threadsafe" extension? If you do, please take a look at this page http://www.openssl.org/docs/crypto/threads.html and these words in particular: OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func. locking_function(int mode, int n, const char *file, int line) is needed to perform locking on shared data structures. (Note that OpenSSL uses a number of global data structures that will be implicitly shared whenever multiple threads use OpenSSL.) Multi-threaded applications will crash at random if it is not set Do you think any locking function is implemented in openssl php extension? -j -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
