ghci and ghc -threaded broken with pipes & forking

[Simon Marlow]

John Goerzen wrote:

> The standard way of implemeting pipes between two external programs in
> Unix involves setting up pipes and forking, then duping things to
> stdin/stdout, and execing the final program.  In this case, I am setting
> it up to let people pipe to Haskell functions as well, forking off a
> process that works with pipes to handle them.
> 
> I know how all these things work in Unix, in C, in Python, etc.
> 
> I have no idea how all of this will interact if I were to use forkOS.
> It is not clear to me what the semantics of forkProcess, executeFile,
> signal handling, etc. are under a Haskell thread instead of a forked
> process.  This is, as far as I can tell, completely undocumented in
> System.Posix.* and the subject of differing advice on the WWW.

We can certainly add any missing documentation - can you suggest specifically 
waht you'd like to see mentioned?  forkProcess does say what happens when there 
are multiple threads, and I've added some more notes about I/O with -threaded. 
executeFile isn't affected by threads.  Signal handling unfortunately won't work 
in the child of forkProcess, with -threaded, right now for the same reason that 
I/O doesn't work.

> But let me add a voice to keeping the non-threaded RTS around.  I have
> learned the hard way that the threaded RTS is ported only to a very few
> platforms, a distinct minority of the platforms that Debian supports,
> for instance.  (Just like ghci).  Whereas the non-threaded RTS is
> supported much more broadly (such as Alpha support).  My own program
> hpodder has failed to build in Debian on many platforms because I didn't
> realize this going in.
> 
> Not only that, but it is apparent that the threaded RTS is simply
> inappropriate when a person is trying to do anything remotely low-level
> on the system.  I would hate to have to become a Haskell refugee, going
> back to Python, because Haskell I/O has become incompatible with fork().
> 
> I do not find a language to be useful, in general, unless it lets me
> fork and exec when I have to.

I share your concerns, and doing low-level system programming of this kind is 
certainly something we want to support.  I'd also consider it a serious problem 
if we were to lose the ability to write a shell in Haskell.  (I should point out 
that it's not usualy fork+exec that causes problems, rather fork on its own - 
fork+exec is pretty well supported, we use it in the timeout program in the GHC 
testsuite for example).

Many people really need the facilities that the threaded RTS provides 
(non-blocking foreign calls, SMP parallelism, writing thread-safe DLLs, etc.). 
So we have to provide these facilities without losing support for system 
programming.  I accept we may have tipped the balance a little recently in 
favour of the funky new stuff; apologies for that, and thanks for bringing it 
up.  We won't be throwing away the non-threaded RTS any time soon, certainly not 
while there are certain programs and platforms that only work with it.

Regarding platform support for the threaded RTS: that's certainly a problem, 
which is mainly due to lack of resources.  I'm sure most bugs are probably 
fairly shallow, since we only use Posix thread support.

Regarding your shell: I would suggest trying forkIO for the Haskell "processes" 
(not forkOS unless for some reason you really need another OS thread).  However, 
  I can imagine that it might be hard to implement job control and signal 
handling in that system.  You could also consider using 
System.Process.runInteractiveProcess, for portability.

Cheers,
	Simon