I've reflowing the messages so they stay within 80 columns.
On Fri, 5 Jan 2001 18:37:15 +0100, Torvald Riegel wrote:
>On Fri, Jan 05, 2001 at 11:01:42AM -0500, Rocco Caputo wrote:
[exceptions omitted]
>> 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'll mail out copies on request, but it's several months old and I may
decide to do something else when I have a chance to look at it again.
Any comments on it will go into my to-do pile along with the design,
and I won't answer them until I can resume work on it.
>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.
Input flow control belongs in Wheel::ReadWrite, and it probably can be
done entirely there. I haven't given much thought to how, though.
[more removed]
>> >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?
I don't understand. What sort of implementation?
[global event handlers are a convenience]
>> 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.
I'm not really a computational theorist, so I'll now reiterate what
you've said from my point of view to confirm whether I understand you.
Correct me if I'm wrong.
z1 = m( z0, input1 . input2 ) means that a given state transition
function m() will move from state z0 to state z1 after it receives the
combined input (input1 . input2).
So then z1 = m( m(z0, input1), input2 ) should be equivalent, although
m(z0, input1) may move into an intermediate state (say z2). In other
words, the original statement may actually be equivalent to these two
simpler ones:
z2 = m(z0, input1)
z1 = m(z2, input2)
In the simpler case, POE::NFA may work because input2 can arrive after
the state transition is enqueued. However, in the original case,
input1 and input2 are queued before the z0 -> z2 transition, so input2
arrives in z0 where it doesn't belong.
Unless I'm mistaken, that is a strong case for reverting POE::NFA to
immediate state transitions.
[developers should know how to use proper NFAs]
[correct designs would not have race conditions]
>> 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).
This brings back my original problem: How do I allow an NFA to queue
events (not just state changes) if the state can change before they
are dispatched? The easiest answer is to prohibit queued events or
document the behavior as "undefined" until it can be worked out better.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
