[squeak-dev] OSProcess question

Hi -

We have a situation where some code reliably locks up when used like here:

  p := OSProcess command: 'chmod +x ', path.
  [p isComplete] whileFalse.

This hangs quite reliably in the second line and I'm *assuming* that we
need to yield/delay execution while waiting. Is this correct? I was
trying to trace through the code paths which update the runState but it
wasn't immediately clear where this comes from.

Any help is appreciated.

Cheers,
   - Andreas

On Mon, Mar 10, 2008 at 11:13:42AM -0700, Andreas Raab wrote:
Hi Andreas,

Yes, you should add a delay in the loop, or use this (which adds the
delay for you):

  p := OSProcess waitForCommand: 'chmod +x ', path

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. On Unix, this is a SIGCHLD, which is caught by OSPP,
which sends #signalSemaphoreWithIndex:, which wakes up the grimReaperProcess,
which calls #primitiveReapChildProcess to clean up and obtain the child
exit status. After all of this has happened, #isComplete will answer
true.

BTW, you can receive direct notification of a change in run state for
an external OS process (ExternalOSProcess>>update:), but this executes
in the context of the grimReaperProcess, so use this with care.

HTH,
Dave

David T. Lewis schrieb: 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.

Cheers,
Hans-Martin

David T. Lewis wrote:
Thanks, that's what I suspected. It's working great now.

Cheers,
   - Andreas

Dear Hans-Martin,
I was very happy to see your advice. My process is hanging in <(Delay forMilliseconds: 1200) wait>, perhaps this could help..

I do not understand the meaning of   <OSProcess waitForCommand:>
I have looked in Squeak  3.8 and 3.10.
    Neither image has the global constant <OSProcess>.
    Neither image has implemented the method <waitForCommand:>.

Does this only apply to a particular platform? (I run WinXP)
Could you please enlighten me?

Cheers
--Trygve


On 11.03.2008 08:24, Hans-Martin Mosner wrote:

David T. Lewis schrieb:
  

On Mon, Mar 10, 2008 at 11:13:42AM -0700, Andreas Raab wrote:
  
    

We have a situation where some code reliably locks up when used like here:

 p := OSProcess command: 'chmod +x ', path.
 [p isComplete] whileFalse.

This hangs quite reliably in the second line and I'm *assuming* that we 
need to yield/delay execution while waiting. Is this correct? I was 
trying to trace through the code paths which update the runState but it 
wasn't immediately clear where this comes from.
    
      

Hi Andreas,

Yes, you should add a delay in the loop, or use this (which adds the
delay for you):

  p := OSProcess waitForCommand: 'chmod +x ', path

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.

Cheers,
Hans-Martin


  

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

On Tue, Mar 11, 2008 at 11:18:42AM +0100, Trygve Reenskaug wrote:
Trygve,

OSProcess is an external package (SqueakMap/Universes). It is only
partially functional on Windows, and would require that you build
your own plugin on that platform.

Dave

David T. Lewis schrieb:
> ...
>  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.
>  
True, that might lead to undesired results.
And of course, busy waiting is very likely to get you into trouble
anyway, so it might indeed be better to point to "the right way of
waiting for a process" instead of working around questionable uses...

Cheers,
Hans-Martin