[Gc] Re: Problem pthread_atfork

Andy Wingo wingo at pobox.com
Tue Mar 27 06:42:57 PST 2012

Hi Ivan,

On Tue 27 Mar 2012 15:48, Ivan Maidanski <ivmai at mail.ru> writes:

> This is unclear to me. If the client code is:
> GC_fork_prepare_proc();
> pid = fork();
> if (pid) {
>  GC_fork_parent_proc();
> } else {
>  GC_fork_child_proc();
> }
> Is the correct locking order ensured here or not?

This sort of code has two problems.

 1) If the program forks without going through the fork() wrapper, it
 won't get the benefit of GC_fork_prepare_proc().  One case in which
 this might happen would be if a user has a program that forks, and then
 adds Guile extensibility to it.  They are probably calling fork()
 directly and not going through the Guile wrapper.

 2) Consider an MT-aware app that is going to rely on pthread_atfork()
 to preserve some property across a multithreaded fork.  It uses libgc.
 In its own atfork() handlers it should be able to call libgc
 functions.  But it can't do so if you use a fork wrapper, because in
 that case the alloc lock would be already taken when the atfork
 wrappers run.

Related to problem (2) is: a library that wants to use pthread_atfork()
(e.g. libguile, though I think it's a bad idea) needs to ensure that all
libraries that it uses use pthread_atfork() appropriately.  That means
libgc would need to use the pthread_atfork() interface, not a different

The closest I can think of to a correct solution is to have yet another
option to GC_init, that if set will install the atfork handlers.

My two cents, FWIW, etc ;-)



More information about the Gc mailing list