🚀 go-pugleaf

Bill Leonard (bill@amber.ssd.hcsc.com) wrote:
: In article <4e35jg$k8c@galaxy.ucr.edu>, thp@cs.ucr.edu (Tom Payne) writes:
: > If the ABI implementation of signal blocking is missing or has high
: > overhead, then we can use global flags inside the program to reduce
: > blocking to setting a bit and reduce unblocking to clearing that bit
: > and checking whether a deferred signal has arrived (in which case
: > there is additional overhead to check which signal to process it).
: 
: Maybe I've missed something here, but wouldn't that code have to appear in
: every function prologue and epilogue?  The only reason for signal blocking
: (I thought) was that trying to propagate an exception into or through a
: stack frame that is partially constructed or destroyed is problematic.
: 
: I certainly wouldn't want code to check (and handle) a signal to be
: generated in every function prologue!  Talk about code bloat!

We need to shrink-wrap critical sections where the stack might be in
an inconsistent state (prologues and epilogues) against exceptions
thrown by signal handlers.  We can do this by:

  1. setting a flag during such regions,

  2. having the compiler generate PC-range tables telling where 
     these sections are,

  3. using some kind of pattern recognition to determine whether 
     the interrupted function invocation was in a critical section.

Solution #1 involves at each critical section two writes and a
conditional jump around a call to a function that throws deferred
exceptions (as a proxy for the signal handler).  Solutions #2 and #3,
proposed by David Chase, involve no overhead in time, but #2 involves
some space overhead.

Steve Clamage has raised the question of existing libraries.  Under
solutions #1 and #2, such libraries would have to be recompiled or
else calls to them would have to be shrink-wrapped for the duration of
the called function (leading to objectionable latencies if the
shrink-wrapping blocks ALL signals).  Solution #3 would eliminate the
need for recompilation, but you and Steve have expressed doubt about
the feasibility of being able to programmatically detect these
critical regions.


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