On Fri, Jan 05, 2001 at 11:01:42AM -0500, Rocco Caputo wrote:
>
> 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.
>
I would agree. At least as long as exception are supposed to have "more
context" than just the who called it or something like that. although
this would require tracking who called what which probably is not needed
by most POE applications.
>
> 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.
Is it available to everyone? I'd be interested.
i didn'T investigate my issue (separate input notification and input reading
for wheels) any further because I though I'd better ask you about it before.
But I had a quick look at the code and thought that it would need patching
of POE::Kernel and at least a new wheel interface. Which I assumed to be
a major issue.
And I guess the problem affects a lot of people. If you have high amounts
of incoming data, it all gets put into perl variables. As wheel events
are synchronous this might lead to other events not dispatched as fastly and
memory usage growing _rapidly_. The same if the other end cannot put data as
fast. And reading from files should be done with wheels otherwise some fs
types (nfs, ftp, ...) might block the whole application.
>
> >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.
but this is not how it should be handled. I'm not struggling because I don't
know how to handle it but because I can't handle it as i would like to / need.
it's all about the immediate state transitions, below, ...
>
> >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.
hmm ok, I thought it would match and NFA's could behave like sessions. at least
if there would be like I'd like them to be :)
anyway, would you be interested in an implementation approach?
>
> Global event handlers are only an issue of convenience. You can
> implement them in plain Perl:
yeah it's just about construction convenience. up to now nobody will need
it anyway, i guess. and not in a way that having the handlers in all states
would let the nfa grow too much.
>
> 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.
I don't agree. "Real" NFAs act according to their current input, and this
includes state changes. For these state transitions aren't part of input
data at all. The programmer/designer of a machine is responsible for doing
the right thing, even if input is generated by the machine itself.
you can (roughly) describe a machine with state z = m(z0, input_band), m being
the transition function. and theorie says that if z1 = m(z0, input.input1) is
true than as well z1 = m( m(z0, input), input1 ). And this requires immediate
state transitions, otherwise input1 can never be in context of input.
Of course work arounds are as easy as setting flags or the like, but that'S
like building a real nfa on top of poe::nfa, which probably isn't wanted.
>
> 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:
if this is intended it is ok. and developers should know a bit about
machines so they shouldn't get confused.
>
> 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:
No, it is not. Assuming that the machine's author came up with a correct
design. (because of the above equation).
>
> 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.
Well, having a possibility to post state transition is useful, of course.
But you should separate them from the immediate state transitions that are
used in machine theory. Splitting it up into posted and immediate state
transitions is probably the best way, limiting immediate state transitions
to the event handlers (only they have a reference anyway).
I don't think that it is a problem to have synchronous events. As long
as event handlers are atomic everything is fine (meaning NFA requirements
are satisfied). And once you got used to the what the above equation
means designing machines gets even easier. And it is deterministic this way
and a real NFA.
About the order of incoming events: the machine has to handle its input.
if synchronous events get processed before other events it is ok because
we have immediate state transitions and atomic event handlers (equal to
an atomic transition function). Queueing them doesn't help, it's just
another version of the race result (if you have immediate state transitions,
without them, you are right, because you couldn't have atomic handlers
otherwise).
torvald
