[Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
alexander.kjeldaas at gmail.com
Mon Jan 21 08:28:16 CET 2013
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
> - 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
> - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe