Re: more on exceptions; new handler

[Paul Kienzle]

On Fri, Nov 15, 2002 at 01:22:31AM -0500, Paul Kienzle wrote:
> On Thu, Nov 14, 2002 at 09:50:50PM -0600, John W. Eaton wrote:
> > Currently, I've defined macros in libcruft/misc/quit.h so that our new
> > interrupt handling scheme can work with or without exceptions.  But
> > does this really make sense?  Should we just start using exceptions?
> 
> We are at this point very dependent on a standard C++ compiler, so assuming
> exceptions is not going to cost us anything in terms of portability.  
> 
> To be sure that this is the case, I would like to see your except.cc
> extended to handle all the cases (fortran code, callbacks, dynamic loading)
> so that we can see how well it does (or does not) work on various
> platforms.  I'm too tired to do anything about it tonight though.

Okay, I played with exceptions some more.  The attached except.cc does
work rather than sleep each iteration so you can see that pressing
Ctrl-C does not actually get you to the next iteration any faster.  Sleep
returns immediately after a signal even if the allotted time has not
passed.

I tried throwing an exception directly from the signal handler but that
didn't work.  So it looks like we will indeed have to use this screwy
system of wrapping any computationally intensive code (even C++ code!!)
in the setjmp/longjmp equivalent of try/catch.  How about a START_OP
macro to push a new jump buffer, and END_OP to pop it.  No resource
allocation is allowed between START_OP and END_OP otherwise we would
need to parameterize the START_OP with clean up code.

I still don't know what happens if you throw an exception from a callback
through Fortran code which was not compiled with -fexceptions.

Paul Kienzle
address@hidden

except.cc
Description: Text document