One reason would be to allow for a product like APD to do JIT swapping of executors to enable tracing on demand. I imagine you could come up with a clever way of letting Zend (En|De)coder be used for oly prticular clients in a large vhosting operation as well (although I don't really know how that product works.)
George Andi Gutmans wrote: > If there's no concrete reason it is needed I think things should stay > as they are. > One reason - it's slower, probably not noticeable but it still is. > > Andi > > At 03:06 PM 10/14/2002 +0100, Nick Lindridge wrote: > >> > why would one want to have different executors/compilers in >> > different threads? >> >> I can't answer this question Thies, and one could achieve it as-is by >> having a thread safe delegator, but as far as possible I'd suggest that >> publicly exposed features of the engine should work across supported >> platforms, and isn't the case with these hooks. >> >> I remember the days when myself and other kids were writing machine >> code non-flicker software on Sinclair ZX80's, and that was thought of >> as 'impossible' (as the CRT hardware was driven by software and any >> operations caused flicker), but actually this was possible if you'd a >> Z80 handbook to hand and didn't mind counting instruction cyles on all >> the possible branch paths, and pulled some tricks. >> >> This is just in my view and experience, but people will always use >> features and do things that designers of said features could never have >> conceived. Equally people will solve problems in different ways to >> others, and one has to mindful of this and accordingly endeavour to >> design without artificial constraints. If one knows that modifiable >> globals should be made thread safe on a threaded server then unless >> there's a good reason to not do it, it should be done, and not omitted >> just because the developer 'didn't think that it would be useful'. >> Genuine omissions, as was probably the case here, are fine, and we all >> make them, but should then be scheduled for correction once discovered >> for the benefit of future developments, and to improve the quality of >> the product as a whole. >> >> >> >> >> >> -- >> PHP Development Mailing List <http://www.php.net/> >> To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
