Process library and signals

[Simon Marlow]

On 27 October 2004 15:08, Glynn Clements wrote:

> Simon Marlow wrote:
> 
>> So basically you're saying that if runProcess is to be used in a
>> system()-like way, that is the parent is going to wait synchronously
>> for the child, then the parent should be ignoring SIGQUIT/SIGINT. 
>> On the other hand, if runProcess is going to be used in a
>> popen()-like way, then the parent should not be ignoring
>> SIGQUIT/SIGINT. 
> 
> Exactly.
> 
>> The current
>> interface doesn't allow for controlling the behaviour in this way.
> 
> Yep.
> 
>> So the current signal handling in runProcess is wrong, and should
>> probably be removed.  What should we have instead?  We could
>> implement the system()-like signal handling for System.Cmd.system
>> only, perhaps. 
> 
> Well, probably for system and rawSystem.

I've now fixed system and rawSystem to do something more appropriate on
POSIX systems: they now disable SIGINT and SIGQUIT in the parent, and
reset these signals to SIG_DFL in the child.  This isn't completely
correct, but it's better than before.

runProcess and friends don't do any signal handling.

I think this covers most of the useful situations.  If you want to do
the same thing in both parent and child, or handle in the parent and
SIG_DFL in the child: use runProcess.  If you want to ignore in the
parent and SIG_DFL in the child: use System.Cmd.{system,rawSystem}.  To
handle in the parent and ignore in the child: unfortunately not directly
supported.

I realise this doesn't address the library design issues you raised, but
as you pointed out there doesn't seem to be a good platform-independent
solution here.

Cheers,
	Simon