Re: thread-safety definition

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Dave Butenhof <David.Butenhof@xxxxxx> writes:

> David Abrahams wrote:
>
>>Dave Butenhof <David.Butenhof@xxxxxx> writes:
>>  
>>
>>>David Abrahams wrote:
>>>    
>>Please don't shout, especially to emphasize something I disagree with
>>so fundamentally. ;-)
>>
> Ah. I see the problem. I believe that you neglected to file in
> triplicate the official "List of all matters with which I disagree so
> please don't shout when discussing them" form. Didn't you? ;-)

I filed.  It was *you* who neglected to check with the department of
archival non-shouting topic storage, wasn't it?

>>If you make cancellations behave sufficiently like an ordinary C++
>>exception (either of Nathan's or Jason's models would do that I think)
>>then it's neither "IMPOSSIBLE" nor even difficult.  A great deal of
>>thread-safe exception-safe C++ library code would behave perfectly
>>well under those conditions.
>>  
>>
> Well, it should be no surprise that this discussion has fragmented
> into too many different little pathways for anyone to keep track of
> them.
>
> If cancel is implemented completely as a "full stature" C++ exception,
> and none of the "exception safe" code does anything silly like
> "catch(...)" without a re-throw, then, yes, it's likely to be
> reasonably cancel-safe. 

Even if only *some* of it does that, Nathan and Jason's models are
both likely to result in an eventual cancellation.

> (Though some code might need to be aware that an uncaught cancel
> will terminate the thread rather than the process!)

Remember, we're talking about library code.  Usually it's only used
"on the inside" of threads so it doesn't care whether when it's
terminated, it's the process or only a thread.

> But I was really responding to the ideas about turning cancel into a
> return status

...only for 'C' functions which ordinarily have a return status and don't
throw...  did you miss that?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com