[c++-pthreads] Re: cancellation points report failure

[Dave Butenhof]

Alexander Terekhov wrote:

>Dave Butenhof wrote:
>[...]
>  
>
>>Are you intending to suggest that pthread_setcanceltype() be made a
>>guaranteed cancellation point, ...
>>    
>>
>I'm (once again) intending to suggest that "an act" of transition 
>from synchronous to asynchronous cancellation be made a guaranteed 
>cancellation point so that "passing through" any async-cancel-safe 
>region with cancel request pending on its entry (or by the time of 
>pthread_testcancel() invocation inside async-cancel-safe region [I 
>also want pthread_testcancel() be added to the list of async.cancel
>safe functions]) shall result in raising std::thread_cancel_request 
>exception (subject to PTHREAD_CANCEL_ENABLE cancellation state, of 
>course).
>
Very simply, Alexander, your proposal COMBINES two separate primitives: 
disabling async cancel, and testing for a pending cancel. Keeping those 
primitives separate allows applications to choose the behavior 
appropriate to their needs. Combining them removes that flexibility. We 
could have created two variants of "disable async cancel", one that 
tests for pending cancel and one that doesn't, but there'd be no real 
advantage over disabling and then testing separately.

>Well, to you, this is/was just a matter of control (apart 
>from your async-cancel "phobia"***, so to say):
>
>google.com/groups?threadm=ki1M8.3%24VD1.187532%40news.cpqcorp.net
>(Subject: Re: cancelling one thread from inside another one)
>  
>
Since a "phobia" is an "abnormal or illogical fear", I'd have to say 
you're wrong on two counts. First, I don't fear it; I merely argue that 
it's rarely usable and far too easy to misuse, and that the cost of the 
feature outweighs its value. And none of that is "illogical". 
Furthermore, since some of the C++ people here seem to have enough 
trouble with the idea of cancel as an exception in the first place, (one 
of those rare goals in which you and I are united), nevermind 
introducing the concept of an ASYNCHRONOUS exception, let's just leave 
this alone, eh?

Personally, I would be happy to accept a C++ binding with no way to 
enable asynchronous cancelability, and to avoid defining any C++ code as 
"async cancel-safe".

-- 
/--------------------[ David.Butenhof at hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/