On Tue, Mar 11, 2008 at 08:24:29AM +0100, Hans-Martin Mosner wrote:
> David T. Lewis schrieb:
> >
> > The run state of an external OS process is updated by a separate Squeak
> > process (evaluate "OSProcess accessor grimReaperProcess"), so you need
> > to wait for the grimReaperProcess to react to the external process
> > exit notification.
> This sounds like the grimReaperProcess should be given higher priority
> so it would not be starved by a busy-waiting foreground process.
> I'd suggest at least Processor lowIPPriority.

In practice I find that UserSchedulingPriority works fine, and I would
worry that running it a higher priority could compromise the reliability
of other parts of the system. For example, user interrupt handling
(<alt>-period) has been unreliable in some versions of Squeak, and
it is also possible to "hook" other methods to the grimReaperProcess
(myExternalOSProcess addDependent: foo, then handle the #runState update).
You would not want these handlers to run at artificially high priority.

As for other foreground processes that run 100% busy-wait until an
external OSProcess exits: Don't do that. Either wait on a semaphore,
or put a delay in the loop.

Dave