On Fri, 5 Jan 2001 06:43:53 +0100, Torvald Riegel wrote:
>a)
>There are comments in the postback code saying that it would be highly
>experimental and it wouldn't be sure that it still exists in the next version.
>Is this true?
They were at first, but now they're useful, stable, documented and
common. I'll fix the comments.
>Do you have any other plans about control flow and the like, some kinds
>of event/handler chains. This probably interacts very deeply with the
>exception model which the PoCo::IKC author requested. The two major directions
>are just using the session's hierarchy or putting more semantics on
>everything, to my mind. The last one being not trivial at all, of course.
>The current with sessions and wheels etc. (and POE::NFA) takes everything
>on a nice little abstract level, but maybe it could be even better ...
No, although this is mainly because I have no ideas at the moment. I
think POE's guts are too low-level for exceptions, and they can
probably be implemented cleanly and concisely on a higher level. I'd
be happy if you can convince me otherwise.
>b)
>obsolete with the style guide you announced :)
>this will be very helpful, so everyone knows were development is going to ...
I once tried removing some code I thought was useless. Shortly
afterwards I received a complaint that I'd broken someone's code.
I'll never do this again, at least not without giving fair warning. :)
The style guide is just something I can refer back to when I'm
documenting. It's not a development roadmap. If you want to look
into what I'm doing at any given time, check out POE's SourceForge
project. I keep the main to-do list up to date, because otherwise I'd
forget most of the things I'd planned to do. :)
>c)
>about the wheels, the docs' bug section says they should be replaced by
>a proper stream abstraction. do you have any plans/ideas about it yet?
>i'm really interested in this because i would need some features (the
>different handling of input) and because it's an important piece of POE.
>to me there is another issue: the decision on how much logic should be
>handled by the filters. up to now tehy just translate. it could be useful
>for some applications to be able to call other states in case of errors
>for example. it is not really needed since everything can be done in a
>session and filters could just pass stuff through unchanged. but maybe you
>another approach.
I have a detailed design document for streams, but it's not complete.
I haven't had the inclination to do anything with them recently
because Wheel::ReadWrite does everything I need, and lots of other
things need more attention.
Filters, drivers and wheels have specific roles, and the only class
that interacts with sessions is Wheel. If filters must emit events,
they should do it as out-of-band data passed to wheels, and wheels
should post or call the appropriate event handler.
Wheels are just plain code running atop POE::Kernel and sessions.
It's possible to write new, better, or more application-specific I/O
libraries, and they will work alongside other sessions using Wheels.
If streams ever get written, wheels will not suddenly break or
disappear.
>d)
>NFA, again :) (for the list members, i suggested to make state transitions
>immediate because to me this would not brake cause/effect order/relations)
>just to give an example for the problem: a sessions sends a command (cause),
>and gets to responses, if response two is to be handled in the context of
>the first one, one would have to set a flag. you cannot use a state
>transition because it would race against the second response. and the
>reason to use poe::nfa would be not having to handle an internal state.
This is a case for not making the state transition before the session
receive the second response.
>would it be possibly to implement the nfa functionality in poe::session?
>there could be a global state in which behaviour would be like with
>current sessions. if the sessiosn state wouldn't be the global one it
>should act like poe::nfa. this would be one more test for normal sessions
>and no difference for nfas. it would solve the nfa start state and global
>handler issues too. the main difference is that presently poe::nfa posts
>synchronous calls back to make them asynchronous, isn't it? Rocco, do you
>have any samples illustrating the problems you spoke about (cause and effect
>misbehaviour with immediate state changes and calls)?
No, I'm against moving NFA code back into Session. The two classes
have separate and distinct uses, and it would be better to properly
enhance NFA than to blur the distinction between them.
Please remind me about the nfa start state issue. I've forgotten it.
Global event handlers are only an issue of convenience. You can
implement them in plain Perl:
my %global_io_events =
( input_event => \&input_event_handler,
flush_event => \&flush_event_handler,
error_event => \&error_event_handler,
);
my %some_state =
( %global_io_events, # incorporate global i/o events
some_event => \&event_handler,
...,
);
my %some_other_state =
( %global_io_events, # incorporate global i/o events
some_other_event => \&other_event_handler,
...,
);
# %global_io_events aren't used directly here:
POE::NFA->spawn( inline_states => { \%some_state, \%some_other_state }
)->goto_state( ... );
Now about the immediacy of POE::NFA's state changes.
If an nfa session has a queue containing more than one event,
switching its state immediately would cause pending events to be
dispatched to the wrong states.
Consider an nfa with event-1 and event-2 destined for state-a. If
event-1 switched the machine into state-b before these events were
dispatched, then they would go to state-b instead of state-a. Here's
some code to illustrate what I'm talking about:
sub event_0_handler {
$_[KERNEL]->yield( 'event-1' ); # posted from state-a
$_[KERNEL]->yield( 'event-2' ); # posted from state-a
$_[KERNEL]->goto_state( 'state-b' ); # switch to state-b
}
Under the current code, this means "post event-1 and event-2 for the
current state, and then switch to state-b". If goto_state() were
immediate, however, event-1 would be dispatched to state-b, and
finding out where event-2 went would be even harder. Consider:
my %state_b =
( "event-1" => sub { $_[MACHINE]->goto_state( 'state-c' ) },
);
In the case of immediate state transitions, event-1 would be
dispatched to state-b which would switch the machine immediately into
state-c. Now event-2 would to state-c instead of to state-a like the
instruction order in event_0_handler implies.
Now with queued transitions, the move to state-b in event_0_handler
occurs after event-1 and event-2 have already been dispatched in
state-a. The code in event_0_handler does what it appears to.
I ran into a new problem after queuing state transitions. Namely,
synchronous I/O events began racing against against them. My code
would switch into a new state, but input would race ahead of the
transition event and continue arriving in the old state.
To fix this, I had POE::NFA re-post synchronous Wheel events through
the same queue as the state transitions. Now input after goto_state()
goes to the proper state, and race conditions are solved.
Or to say it in just a few words: Queuing state transitions and input
events simplifies event synchronization and provides deterministic
event dispatch in NFA sessions. You can look at a piece of code like
event_0_handler and know immediately what it will do.
>hmm, that's it for now. Rocco, I don't want to get on your nerves. so please
>tell me if i should stop that and rather wait for something to appear :)
No, go ahead. I may take some time to respond though.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
