🚀 go-pugleaf

In article p6m@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>: In article 22h@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
>: >why shouldn't signal
>: >handlers be allowed to throw exceptions? 
>: 
>: Exceptions are synchronous, and unwind the stack from the point of the 
>: throw to the point of the handler. When an asynchronous signal arrives,
>: what is the state of the stack? Answer: unknown. In particular, the
>: stack might not even be in a consistent state -- arguments half pushed
>: during function entry or half popped during exit.
>
>When accessing any critical, shared data structure, it is standard
>practice to exclude interrupt-sustained pseudothreads (signal
>handlers) that access the same structure by blocking their
>corresponding signal.  The overhead should be minimal.

In time-critical programs on real-time systems, yes, locking overhead
needs to be minimal. Remember we are talking about the C++ language spec,
not an operating system spec. More below.

>: Allowing exceptions to be thrown from a signal handler would place a
>: noticeable penalty on all programs to provide locks on every function
>: entry and exit, even programs that didn't throw exceptions or use
>: signals.
>
>I'm not sure.  Signal blocking is required only in cases where signal
>handlers might collide with interrupted code over a critical, shared data
>structure.  But, independently compiled libraries must be prepared for
>the worst case.

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
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
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.

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
can do in an asynchronous signal handler don't meet those criteria for
inclusion in the C++ standard.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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. ]