> on myMessage
> doYourStuff
> send myMessage to me in 1 miilisecond with messages
> end myMessage
>
This seems like a good pattern for an app driven by a human. The
apps I tend to write launch and then run forever. They constantly
look into a database to see if there is something they should be
doing.
This can be used as effectively for server type apps that never stop,
daemons if you will.
> If you DO use a repeat loop, the 'wait <time> with messages' is pretty much
obligatory right?
Have never used it but it seems like a good thing to include as a
general housekeeping kind of thing.
This is useful to insert into long running tight loops, so the system
gets some breathing space. Whether use this or sends in time, or
both, depends on specific tasks.
> So you can setup an exit strategy and so that pending
messages (such as sends and dispatches) will still be processed, right?
I don't use send in time I just use immediate sends. Current handler
halts until the send completes.
There is place for immediate sends/calls and there is place for sends
in time. Immediate sends/calls are ways to invoke remote handlers
(value for functions). Sends in time are for polled execution,
allowing sort of primitive pseudo-threading. Dispatch I see basically
as a variant of immediate call.
Robert
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
