[Haskell-cafe] Re: getChar + System.Cmd.system + threads causes hangups

[Simon Marlow]

Donn Cave wrote:
> On Tue, 21 Feb 2006, Simon Marlow wrote:
> ....
> 
>>The reason for the deadlock is because getChar is holding a lock on 
>>stdin, and System.Cmd.system needs to access the stdin Handle in order 
>>to know which file descriptor to dup as stdin in the child process (the 
>>stdin Handle isn't always FD 0, because of hDuplicateTo).
> 
> 
> I was puzzled by this;  from a quick review of the source, it seems
> that this is because system calls runProcessPosix, which has optional
> arguments for (stdin, stdout, stderr) for the child process, and when
> value is Nothing the parent's stdin etc. are used instead.
> 
> That last part doesn't seem right to me, so if it's awkward to implement,
> I hope you will consider the possibility that no one needs it.  The
> default value for fd 0 should be fd 0.  A process that intends to change
> the default input stream on this level where the same stream should be
> inherited by children, can open or dup another file onto fd 0.  Conversely,
> if a program contrives to change stdin to something besides fd 0, I would
> have assumed the intent was to avoid any affect on child processes.

That's certainly a reasonable point of view.  Currently the semantics 
are such that you can say

   h <- openFile "out" WriteMode
   hDuplicateTo h stdout
   system "echo \"hello\""

and the output from the echo command will go to the file "out".

I'm perfectly willing to accept that supporting this behaviour is of 
limited usefulness, and even if you need it then you can call system the 
long way using runProcess.

Anyone else have any opinions on this?

Cheers,
	Simon