Re: [Gc] Re: Problem pthread_atfork
ivmai at mail.ru
Mon Mar 26 04:59:38 PST 2012
I see the following workaround:
1. provide configure --enable/disable-handle-fork trigging [NO_]HANDLE_FORK
2. if no such option given, test atfork availability (by linking a code snippet with pthread_atfork).
Could you provide a patch for this please? (since you initiated HANDLE_FORK to be on by default)
Mon, 26 Mar 2012 10:34:06 +0200 Andy Wingo <wingo at pobox.com>:
> Hi Manuel,
> On Mon 26 Mar 2012 09:33, Manuel.Serrano at inria.fr writes:
> > It's not clear to me what would the consequences of disable the
> > pthread_atfork support. Could you enlighten me? Do you think that it could
> > be a possible option to disable this support while we have not understood
> > how this problem should be fixed?
> Here is a micro-summary of the situation.
> If you fork(2) a multithreaded program, the child may only call
> async-signal-safe functions before you exec(3), according to POSIX.
> However on some systems, you might be able to get by with registering a
> pthread_atfork(3) handler that protects your data structures around the
> fork. Libgc has had code to do this for a long time. (Libgc also has
> to update its list of threads in the child, as the other threads go away
> after the fork.)
> However, libgc's pthread_atfork code was not enabled by default. I
> posted a patch to enable it. That was recent, and hence your error.
> I looked at your message and the blog and it doesn't seem clear to me
> what the fix is. Turning off HANDLE_FORK is certainly an option.
> Actually reverting my patch might be the best option. Since that mail I
> decided to follow POSIX, as most libc, etc people don't care about bugs
> involving threads and fork. That's just my situation though. Perhaps
> Ivan or Hans has a better general perspective.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc