> Something like the following seems to be occurring.
>
> The program `Concurrent.forkIO`s several threads. Two of
> these auxiliary
> threads each fork a process (with `GHC.Conc.forkProcess`).
> Just as the
> second forked process is about to `Posix.executeFile`, it
> appears that the
> "ghost" of the original thread (with ID 1) in that
> process--which is not
> supposed to exist in the new process--suffers the "thread blocked
> indefinitely" exception. (Each of my threads protects itself with
> `Exception.catch` and tags caught exceptions with process and
> thread IDs.)
> It is likely that, in the original process, the original thread was
> waiting on a `readChan` at the time of the `forkProcess`.
Looking at the code for forkProcess, it appears that "main threads" are
not killed in the child process. Thread 1 is almost certainly a main
thread, which explains why it isn't being killed.
This is a deficiency in forkProcess (which I wasn't aware of, or had
forgotten). It looks like the right thing to do is to make the current
thread into the (one and only) main thread in the child process at fork
time.
In the meantime, could you perhaps fork from the main thread instead?
> What I describe above happens nearly all the time. However,
> one time I
> observed something superficially quite different. One of the
> processes (I
> suspect the second forked one, as above, though since the
> message comes
> from the RTS it isn't tagged with a process ID) reports:
>
> Test: main thread exited (uncaught exception)
>
> and then a bit later:
>
> Test: fatal error: schedule: invalid what_next field
>
> That process then exits with `ExitFailure 254`.
That looks like a bug. If you see it again, could you capture the
sources and send them to us? (even if it isn't 100% repeatable).
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
