On Tue, Jan 29, 2002 at 11:17:21AM -0700, Chris Fedde wrote: > Will there ever be a time when mutex conditions and control variables > will be important to POE or POE's users? If POE becomes threaded > can I still blythly use the global environment with the assumption > that POE is serializing access to the global (non $_[HASH]) namespace?
I think it's safe to say no on that, for the same reason Arthur mentioned. On the other hand, if POE can be made aware of global namespaces, maybe it can synchronize them. That will be slow, though, so I don't know. I'm certain POE will eventually support threads, and it will serialize access to $_[HEAP] and POE::Kernel. Those ideas were explored in late 1999, in a conceptual prototype of a "next-generation" POE code named (boringly enough) "POE2". At the time, the basic design goals for POE2 were: 1. Threads aren't used by default. 2. POE's default behavior if threads aren't compiled into perl will be to fake it the way it always had. Programs will continue to work, although they may not work very well. 3. HEAP and Kernel are synchronized so sessions don't have to worry about their local storage. 4. Groups of sessions can run under the same thread, so 1000 sessions does not necessarily mean 1000 threads. 5. Sessions not explicitly asked to run in a new thread will run in thread 0 with the Kernel. Threaded sessions and unthreaded ones can be mixed in the same program. 6. Events dispatched within a thread are done so serially. Session execution is serialized this way, and it should preserve dispatch determinism. This was a long time ago, and there may be other goals that I've forgotten. POE archaeologists can request copies of the last POE2 development snapshot. As with other dark lore, it may do terrible things to the minds of people researching it. :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
