[Haskell-cafe] forkProcess, forkIO, and multithreaded runtime

[Alexander Kjeldaas]

On Mon, Jan 21, 2013 at 12:15 AM, Mark Lentczner
<mark.lentczner at gmail.com>wrote:

> Sorry to be reviving this thread so long after.... but I seem to be
> running into similar issues as Michael S. did at the start.
>
> In short, I'm using forkProcess with the threaded RTS, and see occasional
> hangs:
>
>    - I see these only on Linux. On Mac OS X, I never do.
>
> Previous versions of the linux pthreads library didn't hold any shared
resources in locks, so pthread_mutex_destroy could not hang.  Now Linux is
much improved, and thus it hangs (see pthread_mutex_destroy man page) ;-).


>    - I'm using GHC 7.4.2
>    - I noticed the warning in the doc for forkProcess, but assumed I was
>    safe, as I wasn't holding any shared resources at the time of the fork, and
>    no shared resources in the program are used in the child.
>    - WIth gdb, I've traced the hang to here in the run-time: forkProcess
>    > discardTasksExcept > freeTask > closeMutex(&task->lock)
>    > pthread_mutex_destroy
>
> The discussion in this thread leaves me with these questions:
>
>    - Is there reason to think the situation has gotten better in 7.6 and
>    later?
>    - Isn't the only reason *System.Process* is safer because it does an
>    immediate exec in the child? Alas, I really want to just fork()sometimes.
>
> If you immediately do exec() in the child, you can use vfork() which
blocks the parent.  This serializes the actions and makes this whole mess
smooth and consistent.


>
>    - Is it really true that even if my program has no shared resources
>    with the child, that the IO subsystem and FFI system do anyway? Surely the
>    RTS would take care of doing the right thing with those, no?
>
> It looks like the RTS is trying to do a lot of things to control all the
Haskell threads etc.  But I don't think it waits for FFI-land threads
before commencing a fork(), so that's why I'm guessing that some
interaction between threads using FFI and fork() could be the issue.

>
>    - There should be no concern with exec w.r.t. library invariants since
>    exec is wholesale replacement - all the libraries will reinitialize.
>    Is there a problem here I'm missing?
>
> I think that's right. vfork() + exec() can be serialized and deterministic
thus is a lot easier to reason about.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130121/e567c69d/attachment.htm>