🚀 go-pugleaf

Dick Menninger (Dick.Menninger@daytonoh.attgis.com) wrote:
:
: > ==========Steve Clamage, 1/16/96==========
:  
: > In article 22h@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
: 
: > >Implicit in a qestion of what the Standard says are the related
: > >questions of what it should say and why --- why shouldn't signal
: > >handlers be allowed to throw exceptions?  (The question seems both
: > >interesting and appropriate.)
:  
: > [...]
: 
: Signal handlers are analogous to interrupt handlers at
: application level.  They form separate asynchronous
: processing that may communicate to the rest of the
: application but are really a separate thread.  How they
: communicate to the rest of the application is colored
: thoroughly by their nature.  The problem in thinking
: about exceptions in signal handlers seems to be that
: everybody is treating them as part of the thread they interrupt.
: That leads you down the path to oblivion.  They should
: be seen as a separate thread of execution.  An exception
: does not go back through the special save boundary.
: To do that would be like an exception in one thread
: continuing through another threads stack.  When you
: look at a signal handler as a threadlike thing that happens
: to preempt another thread, you start making sensible
: decisions that allow a signal handler to do that little
: more that is probably necessary.  Since exceptions
: are required at rather basic levels now, precluding
: them is very unrealistic.

Good analysis, but I'm unclear about the conclusion.  Functions called
by signal handlers should be allowed to throw exceptions.  If,
however, the signal handler itself throws an exception or fails to
catch one thrown to it, then the situation seems analogous to the base
function of a thread throwing an exception or failing to catch one
thrown to it.  Shouldn't we consider that a bug?

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