Re: Destructors and program termination
On 6 Aug, 06:36, Michi Henning <mi...@zeroc.com> wrote:
I'm in the situation where I need to terminate a threaded program
from within a signal handler. I cannot call exit() because global
destructors may find data structures in an inconsistent state
and crash, or may deadlock on various mutexes. So, I'm calling _exit()
instead, which (at least for many implementations) prevents global
destructors from running.
Looking at the problem in a larger scope, terminating the application
with 3rd party libraries without giving them a chance to execute clean-
up routines leaves your execution environment in undefined state. One
example is when a library allocates POSIX named shared memory, whose
filesystem name is supposed to be unlink()ed on exit(). Not giving it
a chance to unlink() leaks operating system resources (the ones that
have lifetime scope longer than that of a program).
[...]
The worrying thing is that the standard doesn't say anything about
exit() or _exit(), so I'm relying on implementation-dependent behavior.
Note that the problem also arises for non-threaded programs: in general,
it is not safe to call exit() from a signal handler because that might
cause undefined behavior (because data structure may be in an
inconsistent state, causing destructors to fall over). _exit()
usually works, but does not exist as far as the standard is concerned.
Signal handlers are notorious for being a bad place to do any calls,
apart from a small list of async-signal safe functions (see the list
at the bottom of
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_04.html#t
ag_02_04).
The solution is to defer the work to normal (as opposed to signal)
execution context, what is usually done by self-pipe trick (http://
cr.yp.to/docs/selfpipe.html): having the signal handler write a byte
into a pipe, which is later read by some other thread. Having read the
pipe, that thread would make the other threads shutdown gracefully and
conclude by making the main thread leave main(). It is easily
achievable on practice even with 3rd party libraries, since they
normally provide library init/deinit functions or (reference counted)
library init objects.
The root of the problem is the assumption that terminating directly
from a signal handler is a good idea. This idea ignores the existing
good practices and leads to the necessity of having a quick exit
function (may be with at-quick-exit handlers), which is, IMHO, an ugly
language hack. The real solution is to not terminate from the signal
handler, rather defer that job for normal execution context. From the
normal context you can terminate gracefully while having available all
the standard C++ facilities, such as destructors.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]