On Wed, Oct 03, 2001 at 09:00:49PM +0200, [EMAIL PROTECTED] wrote: > > So handling an event is only possible if the lock is released, otherwise it > will stay in the queue and get handled later. Declaring the needed locks > (or any other resource) before running the handler removes the need for > threads or true peemtable handlers. But you cannot do everything efficiently > with this approach if the handler needs a lot of resources.
Handlers will be atomic for the forseeable future. The current threaded POE designs place sessions entirely within a thread, and handlers are not pre-emptable. Instead, sessions can be running in parallel: one blocking session only blocks itself. A variation on this is to allow several sessions to coexist within a "group". The group manages a thread and a queue, both of which are shared by the sessions within it. Event handlers can block all the sessions within a group, but groups don't interfere with each-other. A group can have only one session. > The handler should release the lock if it has finished working. It would be > fine if the session or something else would trace calls and maintain some > sort of call stack for sessions. That's what I want to do in the script > module, but it's hard to make it fit POE and Perl development as some things > like named params will be in future versions. And I'd like to show some > example code but I don't really know how POE will evolve and how to make it > fit best. Additionally it gets an object layer if you work on it and include > everything that would be needed. Paused events will complicate the queue and dispatch logic. For now I'm experimenting with pausing the event generator instead. From this point of view, it looks like a simpler flow control issue. Is it too simplistic, though? What problems have I overlooked? -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
