🚀 go-pugleaf

> ==========Bill Leonard, 1/22/96==========
> 
> In article <4dos4l$ra9@engnews1.Eng.Sun.COM>,
> clamage@Eng.Sun.COM (Steve Clamage) writes:

[stuff deleted]
 
> Now weigh against that the benefit, if there is any, of allowing an
> exception to propagate out of a signal handler.  Does it buy you

The original issue seemed to be that exceptions could
not be permitted because they would have to propagate
out of the signal handler "by an internal mechanism of
the C++ run-time environment" but this assumes the point
has shifted to whether they cross the boundary.  Of course
they do not need to be allowed to propagate out as an internal
mechanism of C++.  The application must convert them to
a form that can be picked up, when sensible, by application
specific code, just as must happen between threads when
the exception has broader context than can be handled
in the signal handler or thread experiencing the exceptional
condition.  But there still needs to be some basic support
for exceptions unfolding the stack within the signal handler's
stack frame and overridable default handling of exceptions
that make it to the boundary.  I do not see that as being
much different, except in minor details, from multi-threaded
cases where exceptions in one thread may require
application-dependent notification of other threads.

> enough to
> *require* RISC compilers to throw away huge performance gains?
 Not in my
> opinion.

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.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. ]