[Gc] Re: Problem pthread_atfork

[Boehm, Hans]

I'd also be inclined to revert the patch making HANDLE_FORK the default.  I still don't fully understand why this breaks.  But even if it didn't, I agree that invoking the collector between fork() and exec() remains questionable.

Hans


> -----Original Message-----
> From: Andy Wingo [mailto:wingo at pobox.com]
> Sent: Tuesday, March 27, 2012 7:43 AM
> To: Ivan Maidanski
> Cc: Boehm, Hans; Manuel.Serrano at inria.fr; gc
> Subject: Re: [Gc] Re: Problem pthread_atfork
> 
> 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
> interface.
> 
> 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 ;-)
> 
> Regards,
> 
> Andy
> --
> http://wingolog.org/