[ILUG] signals and c++

[Kenn Humborg]

> In the absence of such massive cleverness though I imagine that Im 
> just going to have to live with the ugliness of signals crapping all 
> over the destructors of a program, unless anyone has any cunning 
> ideas.

You probably will.  Support for turning signals into language
exceptions requires run-time library support (such as libg++
registering handlers for all signals and either converting them
to C++ exceptions at the current PC, or passing them to handlers
you registered with the normal sigaction() function), or a
well-defined, language-neutral exception passing mechanism
that all the compilers adhere to (as in VMS, Win32).

Unfortunately, these are all going to be non-portable, so
you are left with handling these as you say: wrap calls to
dangerous functions with signal handlers (to catch the
synchronous signals like sigpipe and segv).  This would
be part of your OS abstraction layer anyway.  

For asynchronous signals like SIGINT, it really depends on what
you are trying to do.  What are you trying to achieve by ensuring
that destructors get called?  

o  Are you trying to ensure that resources get deallocated?
   That doesn't matter if the process is going to be killed.
   (See note below on affecting stuff outside the process.)
   If the signal will be handled and ignored, then it doesn't
   matter because the code won't notice it.

o  If you want to use a signal to partially unwind the call
   stack, and use destructors for resource deallocation and
   cleanup, then it's really tricky.  This is really the
   only case that requires further thought. 

If you are using destructors to ensure that actions that 
affect stuff _outside_the_process_ are performed, DON'T!
Given that there are always ways of killing a program without
destructors being called (SIGKILL, power failure, etc) I'm 
always reluctant to use destructors to perform actions that
affect stuff outside the process.  For example, using a 
destructor to write a trailer and close a file once it is
no longer used is a bad thing (it's a bad example, I know).
Better to re-design your files/shared memory/database such
that inconsistent states are impossible or recoverable.

For example, setting a 'locked' bit in a shared memory 
data structure is a bad idea.  Better to use some form of
OS-supplied mutex or semaphore that the OS will guarantee
to release if your process goes away unexpectedly.

Later,
Kenn