=?koi8-r?Q?Re[2]=3A_[Gc]_On_cancellation, _GC=5Fthread=5Fexit=5Fproc_is_never_called?=

Ivan Maidanski ivmai at mail.ru
Sat Apr 10 06:20:16 PDT 2010


Fri, 09 Apr 2010 17:45:47 +0900 NIIBE Yutaka <gniibe at fsij.org>:

> 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
> files.
> 
> 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
> > http://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
>      GC_inner_start_routine.
> 
>      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.
> -- 

I could agree with You. But, again, it's up to Hans whether to commit this patch or not.

Bye.


More information about the Gc mailing list