Hi, 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). Regards. Sun, 20 Mar 2011 00:26:19 +0100 Andy Wingo <[email protected]>: > Hi Ivan, > > Thanks for the response. > > On Sat 19 Mar 2011 20:18, Ivan Maidanski <[email protected]> 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 > possibilities. > > 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 > libgc. > > > 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 > pthread_create. > > Best regards, > > Andy > -- > http://wingolog.org/ > _______________________________________________ > Gc mailing list > [email protected] > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
