[c++-pthreads] Re: pthread_cancel and EH: let's try this again

[Nathan Myers]

On Tue, Jul 19, 2005 at 09:45:39PM +0200, Alexander Terekhov wrote:
> 
> Nathan Myers wrote:
> > > new_thread(library_call, arg);
> 
> What makes you 
> think that library_call isn't start_routine (aka conventional
> "thread-main" in your thread programming neighborhood), or its
> equivalent apart from "activation records"?

As I said, it doesn't matter if it is or isn't.  You may read that 
again right here:

> > > > Second, when the default is to have cancellation off, design
> > > > heuristics change accordingly.   It would be perfectly
> > > > reasonable to enable (some form of) cancellation, temporarily,
> > > > inside a library that necessarily must have been called with it
> > > > turned off.
> > >
> > > And how would you really turn it off (depending on client's
> > > need/context), then?
> > 
> > ...  If the client calls into a library that promises to
> > throw if it can't satisfy its postconditions, then it might get an
> > exception to deal with.
> 
> My question was about control of cancellation in a thread that can 
> be a target of pthread_cancel().

Any pthread can be a target of pthread_cancel().  If you want some 
mechanism to ensure that a thread always ignores cancellations, 
regardless of any calls it, or libraries it uses, perform, I have 
nothing to propose.  

What we're talking about here is mechanisms to control what happens 
when a thread is already in a cancelled state.  As Wil had proposed, 
a thread in a C++ program starts out with the cancel state having no 
effect on any operation.  If the thread turns on some form of response 
(by constructing one of Wil's objects, however implemented), then at 
any point within its scope where something is supposed to happen (e.g.  
a cancellation point), something happens.  Precisely what happens 
then would depend on what sort of Wil-object is in scope.  

If "what happens" is an exception, then the client sees an exception.
(Library clients don't generally get to say whether they want to handle 
exceptions, iostreams notwithstanding).  

Note that I am not assuming this is all built on top of some existing
POSiX C pthreads implementation, although maybe with some tricky 
linker manipulations it could be.  I interpret Wil's example code only
as a welcome attempt inject some concreteness into the discussion.

Nathan Myers
ncm at codesourcery.com
ncm at cantrip.org