`forkProcess` creates an exact copy of the calling process, except for the return value from `forkProcess` that allows for discriminating the parent from the child. In your example, there are two active threads at the time `forkProcess` is done, so the new process has (copies of) the same two active threads. Then the race is on in the new process: depending on the (unspecified) order of execution, the copy of the initial thread may get to the `print` before its sibling thread gets to do `executeFile` (which wipes away both existing threads). This example raises a general problem (which, as it turns out, is relevant to my current work). How can one mix multithreading with multiprocessing? In particular, how can a threaded process safely create another process to run a program? Put another way, how can the combination of `forkProcess` and `executeFile` be done "atomically enough" so that existing threads in the forking process don't "get in the way". I read something on this topic (involving some sort of pervasive locking strategy) recently, but can't recall where. Anybody remember? Dean Herington Marcus Shawcroft wrote:

Hi,

I want to use a thread in concurrent haskell to manage a posix fork/exec/wait. I expected the test code attached below to output "recovering result" once, instead I get "recovering result" twice. Can anyone shed some light on whats going wrong?

(ghci 5.02.1 x86 linux)

Thanks /Marcus

...

module Test where

...

import Concurrent import Posix

...

main = do mv <- newEmptyMVar forkIO $ do x <- forkProcess case x of Nothing -> do executeFile "sleep" True ["2"] Nothing error "oops" Just pid -> getProcessStatus True False pid putMVar mv () print "recovering result" takeMVar mv