From PBouche at widevine.com Tue Jan 24 17:36:28 2006 From: PBouche at widevine.com (Paul Bouche) Date: Tue, 24 Jan 2006 09:36:28 -0800 Subject: Is the pthread_cancel cancellation exception type known? Message-ID: <07E9B6509C48B54E93107BF41E70DD890238D346@seamail002.widevine.com> 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 From baker at cs.fsu.edu Wed Jan 25 20:43:32 2006 From: baker at cs.fsu.edu (Ted Baker) Date: Wed, 25 Jan 2006 15:43:32 -0500 Subject: [SPAM] - [c++-pthreads] Is the pthread_cancel cancellation exception type known? - Email found in subject In-Reply-To: <07E9B6509C48B54E93107BF41E70DD890238D346@seamail002.widevine.com> References: <07E9B6509C48B54E93107BF41E70DD890238D346@seamail002.widevine.com> Message-ID: <20060125204332.GA4798@cs.fsu.edu> 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 > > From PBouche at widevine.com Wed Jan 25 21:13:25 2006 From: PBouche at widevine.com (Paul Bouche) Date: Wed, 25 Jan 2006 13:13:25 -0800 Subject: [SPAM] - [c++-pthreads] Is the pthread_cancel cancellation exception type known? - Email found in subject Message-ID: <07E9B6509C48B54E93107BF41E70DD890238D6E4@seamail002.widevine.com> 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 > > > > > >