🚀 go-pugleaf

> I think you should probably run the arexx port in a child process. That's

> information back to the main one we have it send a message to the batch guy.
> Much better than pretending to be a Mac program and busy-waiting.

That would be better, yes, but I've generally wanted to avoid forking
a child process until they get easier to set up.  In any case its
changeable later.  It doesn't really busy-wait now - the overhead of
the method it uses to check for ARexx messages is certainly much less
than, for example, blinking a cursor or updating a clock display.  
About 5 machine instructions are executed every 1.5 seconds.  Still,
you're right and it would be better to avoid this at all.  

> Interaction between asynchronous command processors is a complex subject, but
> by and large any given O/S level thread should only have one control flow.
> Particularly is the alternative is busy-waiting.

Not really.  What I need to do is wait on signal A or signal B, whichever
comes first.  No busy waiting, and no child process overhead either.
I was just a little too lazy to try to set that up in 1.5 :-).  Maybe later.

> "setmap" is a poor name, since that's an Amiga program to set the keyboard
> mapping.

Oh well.  Too late now.

   - steve