ghci and ghc -threaded broken with pipes & forking
simonmarhaskell at gmail.com
Fri Mar 2 05:07:07 EST 2007
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.
More information about the Glasgow-haskell-users