Multi stacks = multi processes?

[Dar Scott]

On Tuesday, July 30, 2002, at 06:34 AM, Mike McManus wrote:

> Would I be correct that what I am hearing is, that some processes 
> would be easiest using a send/event list internal to the stack and 
> others "longer running" best  using send/event list sending them 
> off to other stacks rather than substacks? Kinda like spaning a 
> process in unix? Or is there a way to do just that so that 
> multiple processes(stack) of the same process would be running? It 
> will be in OSX after all.

I don't think I explained very well.

First of all, yes, you can use multiple standalones.  You can have 
one that receives requests and sends them off to other running 
standalones or runs them.  You can have a status standalone that 
receives messages and displays them.

The approach I was describing allows you to do this in one 
standalone.  It has some advantages and disadvantages to the above 
method.

I believe there is only one message queue of interest in the whole 
standalone, no matter how many stacks you have.  It is that 
returned by pendingMessages().  There is also an event queue, which 
includes mouse events; handlers are called based on these _after_ 
the messages in pendingMessages() are processed.  That is important 
to note; I think I had trouble getting mouse responses because I 
didn't allow for that.

Here is the send cycle I made when I first started using 
Revolution.  I put this script in a graphic and controlled it from 
a couple buttons.  All it does is make a graphic flash red and 
green.


        -------- Flashing send cycle ---------

local flashing

on change
   if backgroundColor of me is red then
     set backgroundColor of me to green
   else
     set backgroundColor of me to red
   end if
end change

on startFlashing
   if not flashing then
     put true into flashing
     cycle
   end if
end startFlashing

on cycle
   change
   if flashing then send cycle to me in 333 milliseconds
end cycle

on stopFlashing
   put false into flashing
end stopFlashing

       --------


I can put the same code in several graphic controls and they all 
would work.  With a little modification much code can be shared.  A 
clever person might know a way to avoid all scripting in the 
flashing graphic using target or something.

Here, the handler named "cycle" sends the message "cycle".  It can 
send some other message.  You can make whatever state diagram you 
want.  You can even send parameters.

When I used "process" before, I didn't mean a real process, but a 
set of handlers & data bound to a send cycle relationship.  For 
example, if I duplicated the code above in several graphics, each 
might be considered a "process" in some sense.


You can "spawn" these so-called "processes".  Consider what might 
happen if the "if" wrapper in "startFlashing" was left out.  
Calling startFlashing while flashing is going on will get two 
cycles going with the result of a weird flashing.

To "spawn" start and continue cycles with all "spawn" specific info 
in the parameters.  The handler can still look at global info such 
as a global quit flag.

You might be able to pass reference info to the "spawned process".  
For example, you might want the "spawned process" to put the 
contents of a file into a particular variable and to send a 
callback to some object when finished.  Others can explain 
referring to variables and objects better than I.

You can often use the "in 0" when sending.  However, if you have 
problems seeing mouse clicks add a little time to this.

Each handler should finish in a "short" time.  In your case, maybe 
a second or two will be OK (your stop button will be that slow).  
In other cases, this might be in a few milliseconds.

Each handler completes and (unless you do something to prevent 
this) is not interrupted.  It can change values of multiple fields 
and variables and those changes will be consistent.  For example, 
your log field can be updated this way.

If your clients communicate with the server by, say, UDP, then 
include the tcp/ip callbacks in your cycles.  If your app is simply 
triggered by a drop box entry, then create a simple timer cycle (as 
in the flasher) to check the drop box.

If you need to, "modularize," using homemade callbacks.

Others might use some better term than "send cycle".

To make your code easier to read, group send cycle handlers that 
create the same process.  For example, in the above code, "change" 
can be moved to supporting functions.  The remaining variable and 
three handlers form the send cycle.  If you are used to making long 
handlers to do everything, this might paradigm may take getting 
used to.


You might want to consider a third method.  How much will it hurt 
to process each request one at a time?

Dar Scott