Re: [Gc] pthreads and libgc
ivmai at mail.ru
Sun Mar 20 02:45:12 PST 2011
I've modified GC_set_all_interior_pointer(), so it should be possible to alter all-interior-pointers mode even after GC_INIT (not quite sure this will always work as expected although).
If you want to still support v6.8 then I think you should check GC_VERSION_MAJOR/MINOR and use GC_set_all_interior_pointer() if v7.2+.
GC_INIT is a no-op if GC is already initialized.
If you already care about threads registering then you can compile your app with -D GC_NO_THREAD_REDIRECTS (thus avoiding GC initialization in response to a pthread_create).
Sun, 20 Mar 2011 00:26:19 +0100 Andy Wingo <wingo at pobox.com>:
> Hi Ivan,
> Thanks for the response.
> On Sat 19 Mar 2011 20:18, Ivan Maidanski <ivmai at mail.ru> writes:
> > GC_all_interior_pointers cannot be modified after GC_INIT according to
> > the spec. GC_set_all_interior_pointers() has an assertion check for this
> > condition.
> I realize this. We still allow compilation against 6.8, so I can't
> blindly use GC_set_all_interior_pointers, though there are
> However, that's not quite the issue.
> (1) How do I detect that GC has already been initialized, by some other
> module, and so avoid the GC_INIT ?
> > You could compile GC without -D ALL_INTERIOR_POINTERS.
> Unfortunately this is not possible, e.g. on Debian where we use a shared
> > But, anyway, it is recommended to initialize GC explicitly (i.e. by
> > GC_INIT), so placing GC_INIT() (together with
> > GC_set_all_interior_pointer) to the beginning of your main() should be
> > the best way out.
> We can add some documentation to this regard in the manual, if needed.
> But is there no way to get around this, and do the right thing? For
> example, to avoid implicit GC initialization in response to a
> Best regards,
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc