🚀 go-pugleaf

Ugh.  My earlier reply may have been less temperate than I like.
The point I wish to make is that there is no calling-convention-
technical reason making it impossible to implement asynchronous
exception handling on most machines.  The costs vary, but are
usually low, or can be engineered to be low (if you insist on
shrink-wrapping the register saves for every single procedure
that you compile, the costs will be unreasonable, but the obvious
engineering choice is to only shrink-wrap where it is profitable,
and pay the table size cost there).

Furthermore, there are reasons to like asynchronous exceptions.
Sometimes, things are asynchronous.  Timers expire.  People chop
network connections with backhoes.  Printers catch fire.  One
person that I worked alongside, if not with, in two different
jobs, chewed my ear off (even though I agreed with him) on the
necessity for asynchronous exception-handling.

However, there are some language problems with asynchronous
exception-handling.  At the machine level, async exceptions can be
dealt with in an abort/commit/finish-quickly style that always gets you
to a defined state.  To properly deal with asynchronous exceptions, the
abort/commit/finish style has to percolate upward from the machine
level, through every assignment statement, and through every
interface.  With very careful design of the constructor and destructor
interaction, together with careful specification of both concurrent
semantics and pseudo-atomic semantics (pseudo-atomic means atomic with
respect to ones' own interrupt routines, but not atomic with respect to
another thread), this can happen.  Essentially, every operation either
finishes (commits) with its defined semantics, or else it throws an
exception (aborts) and backs out the operation (transaction) to a
well-defined (preferably initial, or an isomorphism of initial) state.
Furthermore, one thread is not allowed to observe another thread's
half-completed operations (implicit in this sentence is some tremendous
handwaving about transaction granularity, since a larger transaction
may consist of a number of smaller ones, some of which may succeed
before the larger one fails, or vice-versa).  Such a language might
be really fun (perhaps difficult, but still fun) to program in, because
if the support for this style worked properly, it should lead to more
well-behaved and failure-tolerant programs.

But, almost nothing that I mention above as a condition for this "to
happen" is true for C++, and I think it is very unlikely that this will
change.

speaking for myself,

David Chase
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]