[Gc] On cancellation, GC_thread_exit_proc is never called

NIIBE Yutaka gniibe at fsij.org
Fri Apr 9 01:45:47 PDT 2010

Ivan Maidanski wrote:
> This seems to be equivalent to your first patch.

It is equivalent for libgc build, but it doesn't touch any header

My intention is to minimize impact by the change.

For libgc users who include gc.h, the first/second patch of mine would
not be good.  Even if a user use -fexceptions for her application, the
change of undefine __EXCEPTIONS forces to use __pthread_register_cancel.
With third patch, it is up to users.

> Did you read
> https://permalink.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3824
> ?  Why not to pull GC_inner_start_routine out into a separate file
> that isn't compiled with -fexceptions?

Thanks for the pointer.  I had not read it.  I read it now.

My opinion is that:

(1) I would agree that it would be better to pull out
     GC_inner_start_routine into a separate file.

     Just FYI, I confirmed that it is not needed to separate it out,
     at least for current implementation.

     For current implementation, compilation of pthread_support.c with
     no __EXCEPTIONS only affects compilation of GC_inner_start_routine
     (specifically, pthread_cancel_push), no effect for other routines.

(2) Only undefining __EXCEPTIONS is better, I think.

     I think that compiling GC_inner_start_routine without -fexceptions
     is overkill somehow.  Yes, it means it goes with no __EXCEPTIONS,
     but it also generates no .eh_frame section for

     No .eh_frame section for GC_inner_start_routine would be OK,
     because it is almost starting point of a thread.

     One minor benefit: If we have .eh_frame section for
     GC_inner_start_routine, it is possible for a debugger to trace
     back to the beginning.  This is perhaps only useful for those who
     chase down to the detail of pthread_create implementation, though.

More information about the Gc mailing list