Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!hpfelg!koren
From: koren@hpfelg.HP.COM (Steve Koren)
Newsgroups: comp.sys.amiga.tech
Subject: Re: SKsh 1.5 release available
Message-ID: <13920082@hpfelg.HP.COM>
Date: 28 Jul 90 22:50:36 GMT
References: <13920076@hpfelg.HP.COM>
Organization: HP Elec. Design Div. -FtCollins
Lines: 28


> 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