Re: [c++-pthreads] Re: cancellation points report failure
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [c++-pthreads] Re: cancellation points report failure
- To: Alexander Terekhov <boo@xxxxxxxxxxx>
- Subject: Re: [c++-pthreads] Re: cancellation points report failure
- From: Dave Butenhof <David.Butenhof@xxxxxx>
- Date: Tue, 06 Jan 2004 06:58:57 -0500
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@xxxxxx ]--------------------\
| 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 ]---/