Re: [PHP4BETA] how does the ZTS work / where are the mutexes?

zeev, On Mon, 16 Aug 1999, Zeev Suraski wrote: > Long one :) > > In essence, a summary of all of the answers below is that PHP does not take > advantage in any way of multithreading; Its multithreaded mode is simply > designed to protect against clashes with global variables. The memory > manager tries to tranparently emulate a multi-process environment. got you.. > > At 16:19 16/08/99 , Thies C. Arntzen wrote: > >hi, > > > >got a few questions regarding the thread-save-mode: > > > >1. how many plist are there (ZTS-mode)? in theory there should be only > >one, right? > > There's one per thread. Having just one for the entire process would > change semantics, and may not work with 3rd party libraries that are thread > safe (they would expect certain local storage to be available, and it won't > be). hmm, module writes should than consider to create their own "private" "global" persistent list - so we can do connection-pooling. i got most of that stuff already in place for oci8 (lucky me;-) - question is: do we want to create an API for things like this? - i think it would be a nice idea. > > >2. all the mutexing is done in zend_hash_add_or_update and friends, right? > > No, none are. Mutexing is done in TSRM - take a look at it and you'll > see. Basically, you must mutex each time you obtain a global resource > (*_FETCH()) and when a new thread is created. ok, i see you point, no mutexing as everything get "separated at birth". > > >3. what happens if 2 requests try to add a persistend connection at the > >same time - or - should we 1st add to plist and then open the connection, > >or 1st open the connection and then add to plist? > > It should be no different from multiprocess mode, because there's no > different semantics for the persistent list there. see above.. > > >4. when & who calles the plist destructors in ZTS mode? > > The thread local storage destructor. > > >5. is all the MUTEX stuff in ext/*.c obsolete? (same goes for #ifdef > >THREAD_SAFE) - and should we *slowly* remove that code > > Yes. When removing, it'd be wise to replace the code with TSRM-compatible > code; The places that contain those #ifdef's give you a good direction on > where to look for thread safety issues. > > >6. can you think of any place where we need to do mutexing ourself? > > There shouldn't be such a place, unless you will be juggling global > resources not through TSRM (not recommended). i'll implement some real global connection list for oci8 soon - i'll check TSRM before doing it;-) tc > > > >7. last but not least, is ISAPI the only testbed fot the ZTS stuff? > > Yes. it would be nice if the unix cgi would compile in ZTS mode. (just for testing) tc > > Zeev > -- > Zeev Suraski <zeev@zend.com> http://www.zend.com/ > For a PGP public key, finger bourbon@netvision.net.il > > > -- > PHP 4 Beta > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany