Re: [Gc] Calling ‘GC_INIT’from a secondary thread

Ivan Maidanski ivmai at mail.ru
Sat Apr 16 02:38:05 PDT 2011


Hi Ludo,

Fixed. Thanks.

Fri, 15 Apr 2011 23:35:04 +0200 ludo at gnu.org (Ludovic Courtès):

> Hi Hans,
> 
> "Boehm, Hans" <hans.boehm at hp.com> writes:
> 
> >> From: Andy Wingo
> >> ...
> >> [From Ivan:]
> >> > 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.
> >> 
> > The problem is that GC_pthread_create needs to allocate memory, and relies
> on some other GC state.  Hence the GC must have been initialized for it to
> work.
> >
> > For newer collectors, it might be possible to instead arrange for
> pthread_create not to be redirected to GC_pthread_create, and for threads that
> need to be known to the GC to register themselves.  I haven't thought through
> whether that might be feasible here.
> 
> With current CVS, it doesn’t seem to be possible to call GC_INIT from a
> secondary thread, as in this example:
> 
> --8<---------------cut here---------------start------------->8---
> #define GC_THREADS 1
> #define GC_NO_THREAD_REDIRECTS 1
> 
> #include <gc/gc.h>
> #include <pthread.h>
> #include <stdlib.h>
> 
> static void *
> thread (void *arg)
> {
> GC_INIT ();
> GC_MALLOC (123);
> GC_MALLOC (12345);
> return NULL;
> }
> 
> int
> main (int argc, char *argv[])
> {
> pthread_t t;
> 
> pthread_create (&t, NULL, thread, NULL);
> pthread_join (t, NULL);
> 
> return EXIT_SUCCESS;
> }
> 
> /*
> Local Variables:
> compile-command: "gcc -Wall t.c `pkg-config bdw-gc --cflags --libs`"
> End:
> */
> --8<---------------cut here---------------end--------------->8---
> 
> This program segfaults:
> ...
> 
> Is it expected?
> 
> > Another imperfect solution might be to set all_interior_pointers and
> probably call GC_INIT in a constructor, either a C++ constructor, or a C
> function that's suitably attributed.  That still fails if other constructors
> run into this problem before our constructor runs.
> 
> If GC_INIT must be called from the main thread, then constructors would
> seem to be the only way to get it called.
> 
> Thanks,
> Ludo’.



More information about the Gc mailing list