Re: [c++-pthreads] thread-safety definition

[Alexander Terekhov <boo@xxxxxxxxxxx>]

Dave Butenhof wrote:
[...]
> >Could it be that the intent was to make pthread_testcancel(), not
> >pthread_cancel(), async-cancel-safe? ;-)
> >
> >
> No. First off, the only reason to use async-cancel, with the associated
> complications and risks, is that you're unwilling to pay the cost of
> calling pthread_testcancel() -- e.g., in a tight computational loop. If
> you are willing to call pthread_testcancel() anywhere you "really want a
> cancel" it'd be just silly to bother with async cancel at all.

Not at all. I want to call pthread_testcancel() at "some intervals" 
(within computational loop) and, at the same time, I want async 
cancel delivery and do NOT want to bother myself turning async
cancel mode off/on just to test for pending cancellation request
and trigger guaranteed delivery.

> Furthermore, despite the looseness in the standard wording that allows
> implementations to ignore async cancel entirely or for long periods,
> this was never the intent. In any implementation of any approximation to
> what the working group would have accepted as "quality", there'd be no
> point at all in making the call when async cancel is enabled.

What if I want to have it "react a bit faster" than a "clock tick"?
What if all of my async-cancel-regions can be passed within "clock 
tick"? To me, "may occur" delivery with respect to async-cancel-
regions is as bad (sort of problematic) as it is with respect to 
optional cancellation points.

> 
> >>but in the end we decided not to risk changing it.) Really, in terms of
> >>POSIX standard APIs, all you can do with async cancel enabled is to
> >>DISABLE async-cancel. I like it that way. There's no reason at all that
> >>ANY of the standard C++ runtime should be designated (or coded) to be
> >>async-cancel safe.
> >>
> >>
> >C++ aside for a moment, I have yet to see async-cancel-UNsafe
> >implementation of, say, strlen(). Care to inspire me? TIA.
> >
> >
> Perhaps, but that's because you've looked. The point is that there's no
> way to know without reading the source. And even if you do, it may
> change on the next edit. You cannot safely PRESUME that anything at all
> is async cancel safe unless that's a documented characteristic of the
> function. Or, of course, if you wrote it yourself and are willing to bet
> that you didn't make any mistakes. ;-)

Heck, let's mandate to have async-cancel-safe strlen()-and-alike
stuff "in-addition-to OR instead-of" async-cancel-unsafe stuff 
and simply use C++ function overloading to pick the right stuff 
(async_cancel_safe inside async_cancel{}), okay?

regards,
alexander.