Multi stacks = multi processes?
dsc at swcp.com
Tue Jul 30 14:25:00 EDT 2002
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
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
-------- Flashing send cycle ---------
if backgroundColor of me is red then
set backgroundColor of me to green
set backgroundColor of me to red
if not flashing then
put true into flashing
if flashing then send cycle to me in 333 milliseconds
put false into flashing
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
You might want to consider a third method. How much will it hurt
to process each request one at a time?
More information about the Use-livecode