The forkProcess# primitive has never worked 100% correctly; I'm currently trying to implement it for the threaded rts, and I see why. It's very hard to get it to work for more than a few special cases.
Calling forkProcess from main (directly or indirectly, but there must be no foreign callbacks in between) should work fine.
The standard idiom of of forking and execing in the child process should work from everywhere; the trouble only starts when the "forked" program tries to return from a foreign exported function or exits by terminating it's (only) thread.
Using forkProcess# for anything else than the standard fork & exec combination is dangerous, and there seems to be nothing we can do about that.
However, if we had
forkProcess :: IO () -> ProcessID (rather than forkProcess :: IO (Maybe ProcessID))
... things would be much safer.
So instead of:
do
maybePid <- forkProcess
case maybePid of
Nothing -> ... executeFile ....
Just pid -> foo pidyou'd have to write
do
pid <- forkProcess (... executeFile ...)
foo pidThis modified forkProcess can be implemented in a reliable way for all special cases I can think of. While it is less flexible than the original type signature, the added flexibility of the current forkProcess seems to be next to unimplementable anyway, so we lose nothing. I'd recommend making this change (or adding a new function and deprecating the old one) at least for GHC 6.4; for 6.2, we could stick with a partially broken forkProcess (which should rather be called "unsafeForkProcess").
Cheers,
Wolfgang
_______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
