ghci and ghc -threaded broken with pipes & forking

John Goerzen jgoerzen at
Thu Mar 1 12:38:54 EST 2007

On Thu, Mar 01, 2007 at 04:21:45PM +0000, Simon Marlow wrote:
> >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.
> I guess I'm really wondering why you need to fork and do I/O at all.  Can 
> you describe the problem at a higher level?

I am, for all intents and purposes, writing what amounts to a simple

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.

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.

-- John

More information about the Glasgow-haskell-users mailing list