🚀 go-pugleaf

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: 
: Suppose that function entry and exit are not atomic operations, which is
: the case on all systems supporting C++ that I am aware of. The "critical
: structure" is the stack frame. If asynchronous interrupts can occur, and
: if you are going to require well-defined exception behavior from signal
: handlers, then you must lock the entirety of every function preamble and
: postamble. (You cannot know that an external signal won't occur.) That

If signal blocking and postponement is implemented with a couple of flags
in the programs static area, we are looking at two writes and a test
at the typical call and return.

: requirement not only slows down function calls, it adds to interrupt
: latency.

: How expensive is it to lock and unlock every function entry and exit?
: On some systems it is cheap. On others it is expensive. Considering that

I think that has to do with efficiency of the signal-blocking aspects
of the signal handling library rather than an inherent limitation of
the underlying architecture.

: a characteristic of OO programs is having many small functions, requiring
: these locks could have a dramatic impact on program performance, even
: for programs that don't want to throw exceptions from signal handlers.

If we use another flag to tell whether an exception-throwing handler
has been installed, then we can bypass the signal blocking when the
feature isn't used.  (Applications that can't tolerate the increased
signal latency shouldn't throw exceptions from signal handlers.)

: What we put in the language standard is binding on all implementations. We
: try to specify things that can be implemented efficiently on any likely
: system. In addition, we try to specify features so that they have no cost
: (or nearly no cost) if you don't use them. IMHO, guarantees about what you

Agreed!!

: can do in an asynchronous signal handler don't meet those criteria for
: inclusion in the C++ standard.

That's a rather broad conclusion, given the discussion so far.
Perhaps the fist implementation that comes to mind (for implementing
exception throwing from signal handlers) doesn't meet those criteria,
even with the patches suggested above.  Still, to dismiss the
possibility of an efficient implementation for this and/or other
asynchornous capabilities seems premature.

Tom Payne (thp@cs.ucr.edu)
---
[ 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. ]