In C++, are global objects guaranteed to exist throughout the execution of a SetConsoleCtrlHandler() callback function?

I'm wondering what would happen if both regular program execution (and the eventual destruction of global variables) and the HandlerRoutine() are racing to complete.

The reason I ask is that my HandlerRoutine() needs to use some global objects, though I'm not sure if they would still exist if regular program termination ended up completing before an invoked HandlerRoutine() call.

I haven't had any problems, though I'm not sure if this is guaranteed.

In C++, are global objects guaranteed to exist throughout the execution of a SetConsoleCtrlHandler() callback function?

I'm wondering what would happen if both regular program execution (and the eventual destruction of global variables) and the HandlerRoutine() are racing to complete.

The reason I ask is that my HandlerRoutine() needs to use some global objects, though I'm not sure if they would still exist if regular program termination ended up completing before an invoked HandlerRoutine() call.

I haven't had any problems, though I'm not sure if this is guaranteed.

• c++
• multithreading
• winapi

• 3 Lifetime of globals is the lifetime of your program - that means initialised during program startup before main() (or WinMain()?) and destroyed after main() returns. So, if you callback is called by main() (or a function it calls, directly or indirectly) the global will exist. You will only have concerns if the callback is called by constructor or destructor of a global object (look up static initialisation order fiasco). – Peter Commented Jan 31 at 17:51
• 1 In general I try to avoid globals completely if I can. So you can create the objects in main and pass references (or pointers) to those objects around. As long as you make sure you synchronize with threads using those objects before main is exited. – Pepijn Kramer Commented Jan 31 at 18:09
• 2 @Eljay I fully agree with you hence my advice to manage lifecycles from the scope of main. E.g. setting up objects, call SetConsoleCtrlHandler to set the callbacks, at end of main synchronize with threads and clear the handler (by calling SetConsoleCtrHandler again). Things can get really really messy when dll's and globals are involved otherwise. – Pepijn Kramer Commented Jan 31 at 18:36
• 2 @DrewDormann The handler is called out of band. This isn't just a callback executed via message dispatch. It runs on a separate thread. – IInspectable Commented Jan 31 at 20:27
• 2 If you don't use some form of synchronization it is possible for main() to exit before the callback completes, so the answer to your question is no, there is no guarantee. Whether this is an actual problem is highly dependent upon what your code does. – Luke Commented Feb 1 at 7:54

1 Answer 1

No, they are not. That is if you mean in terms of object lifetime.

Windows starts a new thread to run your console handler routine on, and it's possible that at that moment main has already finished, and the runtime is in process of executing global destructors. If some of those destructors hangs or deadlocks, and the user presses Ctrl+C in attempt to terminate, then yes, you cannot guarantee which of your global objects are destroyed and which are not.

That said, the allocated address space is still there, and accessing simple variables won't crash.