Multi stacks = multi processes?

[Dar Scott]

On Sunday, July 28, 2002, at 09:48 AM, Rob Cozens wrote (quoting Mike):

>> What I want is to be copying at the same time a file is being 
>> read/wrote and still keep an eye on the directories. each process 
>> working with  different files of course.  Normally Rev would not 
>> do that. But if I put the different processes in different STACKS 
>> or SUBSTACKS? would I be able to get this?
...
> I think you will need to build separate standalones to attain 
> multi processing capabilities in Revolution.

At times this is the right thing, especially when atomic Rev 
commands are too big.

However, often one can limit use of commands to only those that 
take a short time.  The meaning of short depends on your 
application.  In this case each "process" can be envisioned as 
state changes made by simple handlers that finish quickly.  These 
can be integrated into simple domains of send-in-time cycles; use 
both your sends and Revolution callbacks.  You can use variables, 
properties and event the message list to communicate among these; 
no handler is going to be unexpectedly interrupted by another, so 
you can use several.  You can make these domains or "processes" 
modular by making a callback scheme similar to that used by 
Revolution.

(If you have trouble with this style, maybe you can pick one 
"process" to run all the time and sprinkle it with 
wait-with_messages.  Choose the one hardest to fit to this style.  
I would give the send a try for all, though.)

In the case of handling drop-box files, if the operation on any one 
file does not take so long as to affect feedback to a user, I would 
consider doing this as a single "process".

Dar Scott