> 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
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.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!