On Mon, Jan 21, 2013 at 12:15 AM, Mark Lentczner <[email protected]>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
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
