Re: [Gc] Re: Problem pthread_atfork

Ivan Maidanski ivmai at
Mon Mar 26 04:59:38 PST 2012

Hi Andy,

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).

Andy -
Could you provide a patch for this please? (since you initiated HANDLE_FORK to be on by default)
Thank you.


Mon, 26 Mar 2012 10:34:06 +0200 Andy Wingo <wingo at>:
> Hi Manuel,
> On Mon 26 Mar 2012 09:33, Manuel.Serrano at 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.
> Regards,
> Andy
> --
> _______________________________________________
> Gc mailing list
> Gc at

More information about the Gc mailing list