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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
