> To make threading useful, you would need to somehow arrange for multiple > threads to access the same underlying zval data without blocking all > the threads. This just isn't possible AFAIK.
Yes, this is definitely not possible without greatly modifying the engine's zval management (which would introduce tons of locks which would kill performance) > If you want fast read-only access to "shared" zvals, you can serialize > (just like sessions) the zval from the main thread and unserialize it > into your new thread. This isn't strictly read-only, although writes > will only be visible to the new thread. The advantage is that since > the zval lives in the threads own engine/address-space, no > thread-serialization occurs so performance is "better". Automatically serializing is a good idea, though I think the performance loss would out way the benefits. IMO, the main difficulty is having the language automatically handle reads and writes to any value in any thread. The functionality gained from this automation is minimal. If the programmer is required to use a single structure to share data between threads, then it forces them to really think about the IPC between threads. Plus, we get the added benefit of being able to optimize that bridge for the best possible performance. IMO an overloaded object that abstracted a special shared memory structure with read/write locking per member is the way to go. Simple scalar values could be implemented as direct copying, and complex structures (arrays, objects) could use serialization. -Jason > > --Wez. > > > > > > -- > 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
