With our MFC app a normal clean exit calls CWinApp::ExitInstance() and then CWinApp::~CWinApp. But if exit(1) is called, only CWinApp::~CWinApp fires, ExitInstance is skipped. I know exit(1) shouldn't be used with MFC, but we have a legacy app that uses it in 100's of places and I'm wary of replacing it with a PostMessage or something totally different.
What is the best solution here?
Do some magic windows thing so ExitInstance is actually called
Replace exit(1) with something else even though we don't want to
Use atexit somehow to call ExitInstance
Have our CWinApp dtr call ExitInstance, if it hasn't been called already
Try to empty out ExitInstance and just do all cleanup in dtr. Probably not possible?
Other?
It depends on the sort of work you're doing in ExitInstance. You have to make sure you understand what it's doing, and how changing the context will affect it.
With that caveat, the most obvious approach is to move the work you're doing in ExitInstance to a separate procedure, MyExitInstance. Call MyExitInstance from ExitInstance. Replace the calls to exit with calls to a procedure that calls MyExitInstance and then calls exit.
Note that I'm assuming here that's in only your own code in ExitInstance that matters, not anything the framework may be doing for you.
Related
I know you can define functions called init in any package, and these function will be executed before main. I use this to open my log file and my DB connection.
Is there a way to define code that will be executed when the program ends, either because it reaches the end of the main function or because it was interrupted ? The only way I can think of is by manually calling a deffered terminate function on each package used by main, but that's quite verbose and error prone.
The C atexit functionality was considered by the Go developers and the idea of adopting it was rejected.
From one of the related thread at golang-nuts:
Russ Cox:
Atexit may make sense in single-threaded, short-lived
programs, but I am skeptical that it has a place in a
long-running multi-threaded server.
I've seen many C++ programs that hang on exit because
they're running global destructors that don't really need to
run, and those destructors are cleaning up and freeing
memory that would be reclaimed by the operating system
anyway, if only the program could get to the exit system call.
Compared to all that pain, needing to call Flush when you're
one with a buffer seems entirely reasonable and is
necessary anyway for correct execution of long-running
programs.
Even ignoring that problem, atexit introduces even more
threads of control, and you have to answer questions like
do all the other goroutines stop before the atexit handlers
run? If not, how do they avoid interfering? If so, what if
one holds a lock that the handler needs? And on and on.
I'm not at all inclined to add Atexit.
Ian Lance Taylor:
The only fully reliable mechanism is a wrapper program that invokes the
real program and does the cleanup when the real program completes. That
is true in any language, not just Go.
In my somewhat unformed opinion, os.AtExit is not a great idea. It is
an unstructured facility that causes stuff to happen at program exit
time in an unpredictable order. It leads to weird scenarios like
programs that take a long time just to exit, an operation that should be
very fast. It also leads to weird functions like the C function _exit,
which more or less means exit-but-don't-run-atexit-functions.
That said, I think a special exit function corresponding to the init
function is an interesting idea. It would have the structure that
os.AtExit lacks (namely, exit functions are run in reverse order of when
init functions are run).
But exit functions won't help you if your program gets killed by the
kernel, or crashes because you call some C code that gets a segmentation
violation.
In general, I agree with jnml's answer. Should you however still want to do it, you could use defer in the main() function, like this: http://play.golang.org/p/aUdFXHtFOM.
I'm using an API that has a 'bind' function that I call at the start of my program, but to be a good API user, I need to call the 'unbind' function when my program quits for any reason. Is there a way to do that? I can't find anything on Google, and defer api.Unbind() doesn't seem to get called. Thx.
There is no single way to get a 100% guarantee that some code is called before abnormal program termination. The closest you can get is to react to os.Interrupt (and also syscall.SIGTERM on Unix systems) and make sure your cleanup is done thereafter. A good way to achieve this is to use NotifyContext because it ties in nicely with the context package the main use of which is to allow for implementing cancellation of (potentially) long-running code.
I am using FFTW3 at several places in my software. However, these different places/functions/modules do not know about each other, and the order they are called (including their own initialization and cleanup) is impossible to predict. This results in a confusion when it comes to initialization and graceful shutdown of FFTW3.
FFTW3 has a function called fftw_init_threads() which is supposed to be called just once before using any FFTW3 function. Since I don't know which of the application modules (that uses FFTW3) is initialized first, how can I make sure I only call this function once in the entire application?
FFTW3 has a function called fftw_cleanup_threads() which is supposed to be called once at the very end of the application in order to clean up stuff. Any calls to FFTW3 functions after this call will fail. Again, since I don't know which subsystem of my application shuts down last, how can I make sure that I only call this function once at the very end?
One quick solution would be to blindly call the above two functions only at the beginning and end of my main() function respectively. However, this is bad design and not acceptable. The application itself should know nothing about FFTW3. Only the modules that are using FFTW3 should know about FFTW3. My current solution is to have an extra module which acts as a wrapper around the two functions and keeps track if FFTW3 has been initialised or shutdown. If a module requests FFTW3 initialization and FFTW3 is not initialized, then it will call fftw_init_threads(). Otherwise, it will just increase an internal counter and return. Something similar is implemented for the fftw_cleanup_threads() function. This solution appears to work if and only if the modules of the application use the wrapper in order to initialize and shutdown FFTW3.
So I wonder, how do you guys tackle this problem? Is there a way to query the FFTW3 library itself and check whether it is initialised or not? I wasn't able to find something in the documentation.
Thank you
It is safe to call fftw_init_threads multiple times, FFTW3 keeps track of its initialization status (global variable threads_inited in threads/api.c) and will not repeat the initialization if the previous one is valid.
You can call fftw_cleanup_threads multiple times, it knows not to repeat the process if there is nothing initialized.
What you need to avoid in your application is calling fftw_cleanup_threads from a module while others may still be using FFTW.
You could do that with a global counter to keep track of how many modules are using FFTW and only call fftw_cleanup_threads() when the last one is done.
I am willing to run two separate Irrlicht devices, basically a new one after the old one is closed, but by using the two above mentioned methods to close the old one I cannot get the new device to appear (segfault). What is the correct way of doing that?
Just for the clarification.
All the closeDevice() does is just tell Irrlicht to return false on next run() call. It is safe to call it from any part of your code (from the event handler or in the middle of the drawing geometry). Basically you can make your own variable to hold the flag like needBreakRenderingLoop and ignore what run() returns, instead check your variable and change it manually instead of calling closeDevice(). But that is done by the engine already for you.
To fully close a device in a clean way, you must call closeDevice(), then run() to clear all the late events then drop() to clear the memory.
So basically do the following:
device->closeDevice();
device->run();
device->drop();
I know you can define functions called init in any package, and these function will be executed before main. I use this to open my log file and my DB connection.
Is there a way to define code that will be executed when the program ends, either because it reaches the end of the main function or because it was interrupted ? The only way I can think of is by manually calling a deffered terminate function on each package used by main, but that's quite verbose and error prone.
The C atexit functionality was considered by the Go developers and the idea of adopting it was rejected.
From one of the related thread at golang-nuts:
Russ Cox:
Atexit may make sense in single-threaded, short-lived
programs, but I am skeptical that it has a place in a
long-running multi-threaded server.
I've seen many C++ programs that hang on exit because
they're running global destructors that don't really need to
run, and those destructors are cleaning up and freeing
memory that would be reclaimed by the operating system
anyway, if only the program could get to the exit system call.
Compared to all that pain, needing to call Flush when you're
one with a buffer seems entirely reasonable and is
necessary anyway for correct execution of long-running
programs.
Even ignoring that problem, atexit introduces even more
threads of control, and you have to answer questions like
do all the other goroutines stop before the atexit handlers
run? If not, how do they avoid interfering? If so, what if
one holds a lock that the handler needs? And on and on.
I'm not at all inclined to add Atexit.
Ian Lance Taylor:
The only fully reliable mechanism is a wrapper program that invokes the
real program and does the cleanup when the real program completes. That
is true in any language, not just Go.
In my somewhat unformed opinion, os.AtExit is not a great idea. It is
an unstructured facility that causes stuff to happen at program exit
time in an unpredictable order. It leads to weird scenarios like
programs that take a long time just to exit, an operation that should be
very fast. It also leads to weird functions like the C function _exit,
which more or less means exit-but-don't-run-atexit-functions.
That said, I think a special exit function corresponding to the init
function is an interesting idea. It would have the structure that
os.AtExit lacks (namely, exit functions are run in reverse order of when
init functions are run).
But exit functions won't help you if your program gets killed by the
kernel, or crashes because you call some C code that gets a segmentation
violation.
In general, I agree with jnml's answer. Should you however still want to do it, you could use defer in the main() function, like this: http://play.golang.org/p/aUdFXHtFOM.