[SPAM] - [c++-pthreads] Is the pthread_cancel cancellation exception type known? - Email found in subject

[Paul Bouche]

I cannot claim to be wholly familiar with all the consequences
of this issue.  However, it seems by being able to identify the
cancellation exception versus all others, I at least have a 
chance to satisfy the needs of the cancellation process and yet
retain legacy behavior for all other exceptions.  

I do not claim this approach is ideal either, as it still places a
burden on all developers to insure they do not swallow the
cancellation exception in their catch(...) handlers.  All in
all that is still a error waiting to happen.  Yet I believe
it is an improvement over the current situation.

Paul

 

> -----Original Message-----
> From: Ted Baker [mailto:baker at cs.fsu.edu] 
> Sent: Wednesday, January 25, 2006 12:44 PM
> To: Paul Bouche
> Cc: c++-pthreads at codesourcery.com
> Subject: Re: [SPAM] - [c++-pthreads] Is the pthread_cancel 
> cancellation exception type known? - Email found in subject
> 
> I seem to recall seeing this problem discussed at length on this
> list, without development of any consensus on the best way to
> solve it.
> 
> From my own experience with the Ada multitasking standard,
> I lean strongly toward the approach you suggest, i.e., treating
> thread cancellation as a special case, that is always re-thrown.
> 
> --Ted Baker
> 
> On Tue, Jan 24, 2006 at 09:36:28AM -0800, Paul Bouche wrote:
> > 
> > 
> > I have recently been struggling with the conflicts outlined
> > in Bug #160638, regarding pthread_cancel and C++ Exception
> > Handling.  
> > 
> > I have a thread library that has been affected by this problem.
> > The easiest path available to me is to rely upon the previous
> > behavior by using: export LD_ASSUME_KERNEL=2.4.19  until the
> > issue is more formally resolved.   Before doing that, I would
> > like to ask a question that may allow me an alternate solution.
> > 
> > My issue centers around having a catch(...) handler which does
> > not rethrow.   I get the now expected: FATAL: exception not rethrown
> >                                        Aborted
> > 
> > Based on this error, it seems one must rethrow the cancellation
> > exception 
> > to allow it to complete.  Yet, I certainly do not want to 
> rethrow all
> > other
> > exceptions as well.  At least for default behavior, this 
> results in an
> > uncaught exception that Aborts.
> > 
> > 
> > Is the type of this cancellation exception known such that 
> I can employ
> > a specific handler for it and allow it alone to be rethrown?
> > 
> > This allows my catch(...) handler to remain in place, yet allows the
> > cancellation exception to complete as required.
> > 
> > Thanks,
> > Paul Bouche
> >  
> > 
> 
>