🚀 go-pugleaf

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!

> Agreed!!  Note however that an increasing percentage of programs have
> asynchornous aspects to them, under headings such as "event-driven",
> "real-time", "multi-threaded", "parallel", "concurrent", etc.  

Many of those programs also have pretty stringent performance requirements.
Our business *is* real-time, and I've seen many times when getting rid of
just one instruction in a key location would buy a lot of performance.  I'd
be against any requirement that forced me to add instructions in function
prologues/epilogues.

-- 
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
There's something wrong with an industry in which amazement is a common
reaction to things going right.

"Hard work never scared me.  Oh, sure, it has startled me from a distance."
                                                       -- Professor Fishhawk
------------------------------------------------------------------------------
---
[ 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. ]