Re: FW: RE: Re: I'm Lost

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Dave Butenhof <david.butenhof@xxxxxx> writes:

> However when one writes a robust general-purpose facility (library) that 
> will be used in an environment supporting cancellation, that library 
> ought to be written to support cancellation (whether or not it actually 
> uses cancellation on its own behalf). Such libraries are not generally 
> tasks taken on by "casual users"; and even so while hardly ideal it's 
> perfectly adequate to simply say "this facility isn't cancel-safe; tough 
> luck".
>
> "Industrial strength" libraries in the environment, for example the 
> "language runtime" itself, whether libc or STL, ought to be cancel-safe 
> certainly. Even at that, however, because the task can be monumental, 
> POSIX provided "cheats" -- the list of "optional" cancellation points 
> allow a libc developer to omit all but the most critical. A C++ standard 
> for STL *could* provide similar "cheats" to avoid requiring full 
> implementation of cancel-safety. And again, if the user of the library 
> (whether the main application or another library) doesn't choose to use 
> cancellation the point is moot.

Picking this thread up from long ago, lete me say that I'm sort-of in
agreement with the above.  I say "sort of" because Dave B's statement
fails to address the following point (hereafter known as "the
statement"), and I can't tell what side of it he'd come down on:

   Any code that is already exception-safe could be automatically
   cancel-safe depending on our definition of "cancel-safe" and the
   semantics we assign to cancellation exceptions.

In the definition of "cancel-safe" that allows the statement to be
true, cancellation is a request, and doesn't absolutely force
_anything_ to happen.  IIUC, that is the status quo anyway (nobody is
even forced to invoke a cancellation point).

The cancellation exception semantics that allow the statement to be
true are that they act like any other exception, and are not
automatically rethrown at the end of catch blocks.  This is the
question primarily in dispute, IIUC.

IMO, it is worth making cancellation exceptions like any other in
order to make the statement true.  It's also worthwhile to avoid
complicating the mental model programmers must use to think about
exception handling, which, believe me, is hard enough even for many
developers of general purpose libraries to grasp (how long did it take
Dinkumware to make their STL exception-safe?)  Finally, and this may
be counterintuitive at first,

  making cancellation stoppable by catch(...) like everything else is
  sometimes **required** in order to ensure that cancellation
  propagates all the way through the stack and terminates a thread as
  expected without crashing the program.  So those who want
  cancellation to act more like an absolute guarantee of thread
  termination should support it.

For example, I write a C++ library for interfacing with Python.
Python is written in portable 'C' with no special treatment of
cancellation exceptions or the kinds of cleanups POSIX uses to do the
same thing in 'C'.  If I let any sort of C/C++-level exception
propagate into Python, its expectations are violated and will most
likely crash.  It's very common to have a layer of Python sandwiched
between C++ calls on the stack.  I can get proper cancellation
semantics by stopping cancellation exceptions at the boundary and
translating them into Python exceptions.  They'll propagate through
Python, and reach an exception translator on the other side that turns
them back into C++ exceptions.

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