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