Re: Destructors and program termination
On 8/5/07 10:36 PM, in article 6fvti.17054$tp3.96714@nasal.pacific.net.au,
"Michi Henning" <michi@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.
Calling _exit() (which presumably should be "_Exit()") - does not "prevent"
C++ global objects from being destroyed. The destruction of a C++ program's
global objects is not inevitable. Instead a C++ program is responsible for
destroying its own global objects - and can do so in one of two ways: the
program returns from main() or it calls exit(). So a C++ program that fails
to exit main() and neglects to call exit() before it terminates - will not
have destroyed its global objects by the time it ended.
The worrying thing is that the standard doesn't say anything about
exit() or _exit(), so I'm relying on implementation-dependent behavior.
Not so. The C++ Standard specifies that calling exit() destroys global
objects[3.6.3/1] And _Exit() is part of the C99 Standard (and will
presumably be incorporated into the next C++ Standard by reference).
I don't see any implementation-defined behavior here. Calling _Exit() is no
more likely to destroy a C++ program's global objects than calling printf()
- or calling any other function that is not exit().
With threading being added to the upcoming standard, it seems important
that the standard say something about program termination. In
particular, as far as I can see, it is important to provide a portable
way to terminate a program that guarantees that no destructors will run,
and that allows a program to control exit status. Without such a
feature, it becomes basically impossible to terminate a threaded program
prematurely without running the risk of undefined behavior, due to
destructors doing unexpected things.
It's easy to prevent global objects from being destroyed - don't have the
program return from main() and don't have the program call exit() before it
terminates.
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.
The Standard specifies the one routine that does destroy global objects. We
are expected to deduce from that information - the list of routines that do
not destroy a C++ program's global objects.
All alternatives that I can see for terminating safely in response
to a signal are cumbersome. I could, for example, set a flag in
the signal handler, but then all other threads in the program would
have to periodically test for that flag (and some threads might be
stuck in blocking system calls).
Closing the object that the thread is waiting upon (such a socket) is
usually enough to unblock a waiting thread. And certainly the greater the
number of threads in a program, the harder it becomes to shut the program
down in an orderly fashion. So some good advice would be: not to create more
threads than are needed - or to consider a multi-process implementation
instead.
Also, the problem is not limited to asynchronous signals. Simply
terminating a threaded program, for example, in response to user input
(such as pressing an "Exit" button) can require a lot of work: somehow,
I have to signal all threads and get them to terminate in order to
make the program go away.
So, it seems we need something in the standard for this?
I am not so sure. Conducting an orderly shutdown seems to be a program
design issue - not something that the C++ language could directly address.
Until that happens (if it happens), are there any other suggestions
for how I can make my program disappear without risking undefined
behavior?
Once the C++ program calls _Exit() - its behavior becomes nonexistent - not
undefined.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]