RE: System.Cmd.system/rawSystem set stdin/stdout to non-blocking mode

On 09 August 2005 20:56, Adam Sampson wrote:

> While tracking down a bug in Ginsu earlier, I found that the cause is
> an unexpected side-effect of the System.Cmd functions: they set FD 0
> (and consequently anything that it's been dupped to, so probably FD 1
> and FD 2 as well) to non-blocking mode. This will break any future
> usage of stdin/stdout that doesn't expect to get an EAGAIN error --
> for example, Ginsu uses the curses library which won't update the
> screen correctly if FD 1 is non-blocking. Worse, this is done before
> the fork(), so the program that's run is also given its FDs in
> non-blocking mode, and will thus suffer the same problems.
> 
> It appears that this is a consequence of
> System.Process.Internals.runProcessPosix using "stdin", which sets FD
> 0 to be non-blocking.

GHC puts any file descriptor it uses into O_NONBLOCK mode, so that it
can do I/O multiplexing amongst lightweight threads.  The first time you
evaluate stdin, stdout, or stderr they will be put into non-blocking
mode.

We could change runProcessPosix to avoid evaluating stdin, but that
doesn't really solve the problem (and it would change the semantics of
runProcess, albeit in a minor way).

A workaround, if you don't intend to use stdin in your Haskell code
and/or you don't care about concurrency, is to evaluate stdin first and
then explicitly clear the O_NONBLOCK flag:

  do stdin `seq` return ()
     setFdOption 0 NonBlockingRead False

I think it's a bug in Unix that there's no way to set O_NONBLOCK
privately for a single file descriptor.

It just so happens I came across this same bug recently: someone else
reported that you can't pipe the output of GHC through tee

  $ ghc -ddump-simpl Foo.hs -c | tee log

because tee reports a "write error".  This is due to GHC putting stdout
into non-blocking mode, again.

If anyone has any good suggestions, I'm all ears.

Cheers,
        Simon