Hi!
I think that if we were ever to implement threading we would be best off to enable spawning worker threads that have their own context with no shared data (and therefore no requirement for locking). We could then have a message passing API between the threads.
No shared data requires quite new development paradigm though. Imagine you have big application, say, using some Big Framework, that needs to do some mysql queries in parallel. Now what happens is: 1. You can't really just start a thread and run a query whenever you wish to, because mysql connection is probably defined by configs that BF is managing, so you'd have to either create a separate "query server" thread which would keep the connection or open connection anew each time. 2. You can't use objects or anything more complex than an array between threads, since sharing objects means sharing classes and methods, which means sharing data stored there. 3. You still have problems with libraries keeping global state, and many do and even don't bother to tell you about it or provide any means to manage it (e.g. ICU). 4. The overhead of keeping whole set of globals per thread will still be there. Which btw means starting a thread would imply whole RINIT process, along with allocating globals, etc. which may not be as fast as you'd expect.
I think it may be worth trying, but for that we need some good use-case and try to see how it would work out with this use-case.
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
