Re: [Gc] Re: Problem pthread_atfork
ivmai at mail.ru
Tue Mar 27 00:23:13 PST 2012
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.
> > 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).
More information about the Gc