Re: thread-safety definition

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Dave Butenhof <David.Butenhof@xxxxxx> writes:

>>>>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.
>>
> I need to start keeping a scorecard. Lessee here, Nathan's model I
> believe could be trivially characterized as "return failure status on
> any cancellation point until you hit a C++ function allowed to
> throw". This would apparently disable any cleanup operations involving
> cancellation points (they'd fail) at least prior to the first throw
> point -- and it's not precisely clear how the "pending cancel" state
> is to be managed even beyond that point. While it might eventually
> lead to cancellation, it won't reliably perform cleanup. 

I'm having trouble understanding.  How does a "pending cancel state"
perform cleanup?  And what do "reliably" and "cleanup" mean to you?

> This seems to me to be more complicated, less predictable, less
> compatible, and less reliable than simply using exceptions
> integrated with the existing POSIX cleanup mechanism.

That's a rather broad sweep of the judgement brush, accompanied by
little to lend any insight into why you think it's so.

> Jason's model, putting together the puzzle pieces from various
> messages here, appears to be basing cancel on an ordinary
> ("finalizable") C++ exception, which would be raised by any and all
> cancellation points; but if the exception object were to be destroyed
> (by finalization), the "pending cancel" would (might?) be
> reasserted. I personally feel that it ought to be reasonable to
> finalize the cancel and continue operation. If that wasn't really what
> the application intended then it's an application error; but there are
> cases where it's arguably reasonable, and the capability falls
> naturally out of the model. 

I don't have a strong opinion about that, but I'm sympathetic to your
POV.

> Besides, "reasserting cancel" in all the right places and no other
> places sounds like one of those projects that ends up being a lot
> more subtle and error-prone than anyone ever expects. ;-)

I don't really see what you think is complicated about this.  In
Jason's model cancellation gets reasserted as soon as a caught
cancellation exception is destroyed by falling off the end of the
catch block without rethrowing.

>>>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?
>>
> It doesn't matter. There are many problems lurking here, and only one
> of the more obvious is that this attempt to avoid breaking C code that
> depends on 'if (error) {cleanup(); return error;}' will still break if
> 'cleanup()' depends on any cancellation points... which in fact is
> quite likely if 'error' originates from a cancellation point (e.g.,
> I/O). 

In what sense will it break?

> I also don't believe that a sufficient body of library code
> really follows the simple and direct 'if (error) return error;'
> pattern to make this strategy particularly useful even without the
> cleanup issues -- but that's a different matter. 

Before I used exceptions I certainly wrote reams and reams of code
just like that.

> (It might actually be
> better if the pending cancel wasn't "sticky", 

You lost me.  What's "sticky"?

> since then the cleanup at least might succeed; but then you'll lose
> cancels all over the place, and that's definitely not
> acceptable. 

AFAICT you haven't understood Jason's proposal at all, though I may be
misinterpreting your response.

> It's fine for a thread to CHOOSE not to accept a cancel,
> either by keeping cancellation disabled or by not calling a
> cancellation point; but it's not OK to lose a delivered cancel. You
> can declare this to be the application/library developer's job
> rather than the implementation's job -- but that just means all this
> "broken" C code that fails to propagate errors needs to be
> redesigned; and you haven't solved any real problem. That's the
> basic point: it needs to be analyzed and likely redesigned to be
> cancel-safe. You simply can't avoid that requirement.)
>
> A) You cannot transparently make non cancel-safe C code cancel-safe,
> no matter how you try.

It depends how "cancel" is implemented I guess.

> B) Delivering cancellation as a C++ exception will make much (though
> not all) exception-safe C++ "translucently" cancel-safe.

Sure, provided that you only deliver it from functions which could
otherwise throw.

> C) POSIX C cancel-safe code is already cancel-safe, but for an
> application containing mixed call stacks to remain cancel-safe, POSIX
> cleanup and C++ exceptions must be integrated into a single unwind;
> i.e., (by whatever name) basing both on a common exception library.
> D) There are no useful or interestingly large bodies of rigorously
> "cancel-safe" C code that are not POSIX cancel-safe.
>
> In other words, cancel-as-exception, and pthread_cleanup_push as a
> C-based "try" extension, gives you all the cancel-safety you can
> reasonably expect without recoding (and likely redesign). That's all
> that's needed. No less will suffice, and any more is needless
> complication. 

Except for the fact that we have normally-non-throwing functions that
have started to throw, I don't think anyone's disagreeing with you.

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