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

[Ivan Maidanski]

Hi Andy,

Mon, 26 Mar 2012 18:55:43 +0200 Andy Wingo <wingo at pobox.com>:
> On Mon 26 Mar 2012 14:59, Ivan Maidanski <ivmai at mail.ru> writes:
> 
> > 1. provide configure --enable/disable-handle-fork trigging [NO_]HANDLE_FORK
> 
> Sure, will do.

Thanks. Although it is ok to pass it via CFLAGS, --enable-x is more uniform way.

The alternative solution could be use of dlopen or weak symbols (but it is quite target-specific).

Another solution is to let the client decide whether fork should be handled by GC at runtime (in case the client rely on memory allocation after fork)?
(E.g., export GC_fork_prepare/parent/child_proc).

Yet more solution is to redirect fork to GC_fork (which calls prepare, fork, parent/child). Looks to me the best way.
Your opinion?

> 
> > 2. if no such option given, test atfork availability (by linking a code snippet with pthread_atfork).
> 
> Is this possible?  Surely Manuel succeeded in compiling libgc and its
> tests, and the problem only occurred when he went to link libgc to a
> program of his that does -lpthread.

This is unclear to me: he linked to some custom pthread implementation (which has atfork hidden).

> 
> If I may suggest, perhaps the right thing to do is not enable this code
> by default, as it makes otherwise correct programs incorrect.  That is,
> for a program that only calls signal-safe primitives after a
> multi-threaded fork, this patch makes such a program depend on
> unspecified behavior of their OS.

I don't see: where is unspecified behavior if atfork is available? (we just adjust some global vars in GC at fork).

Regards.

> 
> Andy
> --
> http://wingolog.org/