Search the Community

I have a stupid question on how to "gracefully" terminate a Windows console application. I am not very familiar with how processes are established, how parent/child relationships are handled, consoles, all that. I might be missing basics. What I am doing: I have a central application with a VCL interface It uses CreateProcess(..) to invisibly spawn some console applications in the background Some are kept running 24/7, some are just started on demand, crunch some data, then terminate These console applications get their stdIn, stdOut and stdErr pipes redirected to some pipes I created in my central applications, so I can easily process their output, and control them (if they get controlled from stdIn). So far, everything worked like a breeze My issue now: I am now integrating another console application that just runs 24/7 and has no way of gracefully shutting it down It will only end on either pressing CTRL+C on a regular terminal, or by sending it a CTRL_BREAK_EVENT from my central application by using GenerateConsoleCtrlEvent. I know that Windows will "clean up" after the process has ended, but I am not sure if this way of shutting the process down is still a bit too "rude" My question: The documentation of the GenerateConsoleCtrlEvent function states "All console processes have a default handler function that calls the ExitProcess function." The documentation on ExitProcess gets into more detail of what it actually does, but I have a hard time understanding the implications. After sending the CTRL_BREAK_EVENT to the console application, my application will still give it a few hundred milliseconds to power down until it will resort to TerminateProcess but never has to, because the console application will finish within less than 5 ms. I am just unsure whether I am doing it right or maybe there is a better way of "gracefully" shutting down a console application that does not handle CTRL+C at all.