[Tdg] Re: Sequential actions

[Rama Hoetzlein]

Wes,

So, regarding a command that must do a number of actions over a network 
sequentially, I've discovered that its just not possible to write it 
using normal program flow.. Basically, i can formalize the problem. 
Consider the following:

CmdCreateWindow ()
{
    EnumerateDisplays (over network)
    MatchDisplay
    AttachDisplay (over network)
    CreateOSWindow (over network)
}

This is what the handler for a CreateWindow event should do. However, 
each function above must be allowed to run over the network, so they 
must wait until network events are processed.. But the wait should also 
not block the core scheduler so that events can continue in other 
systems (including networking)

One solution is to have some kind of Wait() function that returns 
control to the core scheduler, waiting for a result event.

CmdCreateWindow ()
{
   EnumerateDisplays
   Wait ( EnumerateOk )
   MatchDisplay
   Wait ( MatchOk)
   AttachDisplay
   Wait ( AttachOk )
   CreateOSWindow
   Wait ( CreateOSWindowOk )
}

The problem is, Wait() must return to the core scheduler.. But, if it 
returns control to the core, then it cannot continue where it left 
off... Thus, Wait could not possible work unless it did some funky, 
undesirable stuff with the stack.

This means that "normal looking" programs must all be replaced with 
Event code blocks, with an internal state to trigger the next action.

CmdDrawWindow ()
{
case state1:
    EnumerateDisplays
    Trigger ( EnumerateOk, state2)
case state2:
    MatchDisplay
    Trigger ( MatchOK, state3 )
case state3:
    AttachDisplay
    Trigger ( AttachOK, state4 )
case state4:
   CreateOSWindow
}

So the Trigger function registers with the core for an event to go to 
the next state in a previously started Cmd.. For example, after the 
state1, the trigger causes the core to detects if EnumerateOk comes in, 
and if it does, it consumes it and automatically generates a 
CmdDrawWindow event in state 2.

But the bottom line is, no matter what, I don't see how you're going to 
keep to "normal looking procedural code" (such as at very top of this 
email) when doing certain things that require non-blocking initialization..

Even with Triggers to help you out, functions like this have to be done 
as switches on state. Which means events have to include a state number 
(or call it a sequence number). I don't see any other way.

Rama