ghci and ghc -threaded broken with pipes & forking

[John Goerzen]

On Thu, Mar 01, 2007 at 03:06:22PM +0000, Simon Marlow wrote:
> Ok, what happens here is that in the forked process there is only a single 
> thread, the runtime kills all the other threads (as advertised).  
> Unfortunately this includes the I/O manager thread, so as soon as you do 
> some I/O in the forked process, you block.

Could it just revert to the nonthreaded IO model, or is that not within
the scope of what's easily achievable with the threaded RTS?

> On a more general note, forkProcess is known to be hairy - simply the fact 
> that it kills all the other threads in the system in the forked process 
> means that there's a good supply of means to shoot yourself in the foot, 
> even accidentally. John - perhaps there's another way to achieve what you 
>  want?

Right.  Part of this problem may be one of documentation, and part of it
rests with ghci.

I have no need for threads in this program.  And, in fact, as you said,
threads are known to be hazardous when used in conjuntion with fork().
I have no interest in combining the to.  The mechanics of signal
propogation, file descriptor closing, etc. all get complicated.

But it seems like there is not much choice with ghci.  It appears to be
built with the threaded RTS by default, and uses threads even though I
never try to use threads with it.  And there seems to be no way to turn
it off.

Between that and the lack of support for forkProcess in Hugs, this
renders anything that needs to fork and then do I/O as being usable only
in GHC-compiled code.  Which is sub-optimal, but livable anyway.

Also, why does hGetContents not work, but hPutStr does?  If the IO
manager is dead, how does some IO still work?

-- John