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. Advantages: - Real multi-threading. - Simple straightforward approach which doesn't require a comp. sci. degree to use correctly. - Very stable implementation.
You can tell by this that: a) I think GIL is not the way to go. It's more complex, not truly multi-threaded, and implementation may never be 100%. b) True multi-threading with data sharing in my opinion is a recipe for disaster. Not only because of the implementation complexities but I think it makes life very hard for the developer and requires a lot of sophistication. So if I'd implement something I'd definitely do true multi-threading with message passing (we basically already have the infrastructure with TSRM to support that). Do I think this is a high priority item? Not really but I can understand that it could add value to some. I think for some Web requests it could actually allow for some parallel processing with a rendezvous which could help reduce latency (not overall server throughput). Then again, there'd be some overhead for having a thread-safe build so I don't see this as something that would be enabled by the masses - at least not initially. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
