On Mon, Oct 01, 2001 at 03:05:14PM -0400, Rocco Caputo wrote:
> On Mon, Oct 01, 2001 at 08:38:47PM +0200, [EMAIL PROTECTED] wrote:
> > On Sat, Sep 29, 2001 at 02:10:54PM -0400, Rocco Caputo wrote:
> > > Does anyone rely on I/O events arriving out of order? Right now
> > > they're dispatched without going through the queue, and it makes input
> > > flow control tricky.
>
> [...]
>
> > I would use a general locking mechanism that is applied to input events
> > by defaults. I think this kind of locks is called barrier, only one event/
> > process is active, but unlike critical sections waiting events are
> > processed in order. Barriers could be set even for handler groups.
> > It could be implemented in sessions or in the main event dispatch code
> > (waiting events not being taken from the queue). It would be faster if in
> > sessions (divide and conquer) but session queues would be needed.
>
> I'm totally lost here. Could you illustrate the idea in some
> pseudocode? If I understand correctly, barriers require a pre-emptive
> task manager. That's not going to happen until I get threads working.
POE::Session->create(
...
barriers => {
input => ['input_event', 'input_postprocessing'],
cmd => ['cmd_parse', 'cmd_one', 'cmd_two'],
}
);
could declare that the handlers for the given events (input_event, ...)
are behind some barriers. (I'm not really sure about the correctness of
the term 'barrier', i just try to stick to well known names to make it easier
for everyone).
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.
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.
Torvald
