Re[2]: [Gc] Re: Problem pthread_atfork

[Ivan Maidanski]

Hi Hans, Andy and Manuel,

I agree. I did the following:
1. HANDLE_FORK is always off (unless --enable-handle-fork);
2. HANDLE_FORK replaced with CAN_HANDLE_FORK at most code places;
3. GC_set_handle_fork(int) is added to gc.h (is no-op in single-threaded mode otherwise adjusts GC_handle_fork value);
4. HANDLE_FORK only determines the default value of GC_handle_fork variable;
5. GC_thr_init calls atfork only if GC_handle_fork;
6. If Darwin+MPROTECT and GC_handle_fork is on then GC_dirty_maintained set to off.

Git diff: https://github.com/ivmai/bdwgc/compare/5e7c83290c...e3b0862894

Please test it. If all is ok, I'll merge this commit to release branch.

Regards.

Fri, 30 Mar 2012 04:47:11 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> 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/
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>