[PROGRAMS] Run=CLOSE/KILL, which signal is sent?

[PhilippM]

Hi,

I'm using the [Programs] Run command to start an application I wrote along with the simulator (as Pete advised me to do so here).

I want to terminate my application gracefully when FS is shut down.

For that, I tried inserting the options CLOSE or KILL before the path.

KILL quits my application but doesn't let me do cleanup work, CLOSE doesn't seem to effect my application at all.

I installed the following signal handlers:

signal(SIGTERM, &signal_handler);
signal(SIGINT, &signal_handler);
signal(SIGBREAK, &signal_handler);
signal(SIGABRT, &signal_handler);

But I don't seem to receive any of those signals, neither with KILL nor close.

How can my application notice an FSUIPC-issued close request ?

Regards,

Philipp

[Pete Dowson]

KILL quits my application but doesn't let me do cleanup work, CLOSE doesn't seem to effect my application at all.

KILL terminates the process forcibly, just like using the Task Manager. CLOSE merely sends the processes' main window a standard WM_CLOSE message -- the same as clicking the Close buton at top right in the visible window if it has one.

I installed the following signal handlers:

signal(SIGTERM, &signal_handler);
signal(SIGINT, &signal_handler);
signal(SIGBREAK, &signal_handler);
signal(SIGABRT, &signal_handler);

But I don't seem to receive any of those signals, neither with KILL nor close.

I don't know what they are. Where do you get them from? What are they?

How can my application notice an FSUIPC-issued close request ?

Same way as a close, the WM_CLOSE message, upon which yours or a default Window Procedure would issue a WM_QUIT to cause your message processing loop to exit.

Maybe yours is not a Windows program? If you never register a Window class and create a Window, even a message window (it needn't be visible), then I've no idea how it gets terminated.

Regards

Pete

Regards,

Philipp

[PhilippM]

I don't know what they are. Where do you get them from? What are they?

These are POSIX Signal handlers. http://en.wikipedia.org/wiki/Signal_%28computing%29

But they are supported by windows also, at least for commandline applications

Maybe yours is not a Windows program? If you never register a Window class and create a Window, even a message window (it needn't be visible), then I've no idea how it gets terminated.

Yes, my program is indeed a command-line only programm that runs as a service in backround with no GUI whatsoever. So my only chance to get messages are POSIX-signals.

The other possibility would be to introduce some WinAPI-Code to create an invisible window, as you suggested.

[Pete Dowson]

Yes, my program is indeed a command-line only programm that runs as a service in backround with no GUI whatsoever. So my only chance to get messages are POSIX-signals.

Sorry, I don't know POSIX. How are you getting such "signals" under Windows? How do you normally terminate your program? I can look at providing other methods, but only ones which can be instigated through Windows.

If you know how it is done, let me know and I'll see if i can add it. I looked at your reference http://en.wikipedia.org/wiki/Signal_%28computing%29 and this talks either about sending keystrokes to it (which I wouldn't know how to do because there's presumably no Window handle and therefore no way to set focus or send keyboard messages), or using the Kill facility which you already tried.

It does also say, however, "The kill(2) system call will send the specified signal to the process, if permissions allow ", and lists a SIGKILL signalcouldn't you use my KILL option and process that signal?

Regards

Pete

[PhilippM]

Hi Pete,

thank you very much for your fast support.

Unfortunately, the "kill" in windows doesn't generate any signals as it would on Unix. On Unix, you can't ignore a SIGKILL either, but at least you are notified of your imminent death. On windows it's like being hit by a mini-nuke wthout further ado.

So the Close signal is far more promising for what I want: A graceful shutdown.

I managed to catch the Close-Signal of the Console. One can define a function to handle a Ctrl-C, Ctrl-Close, Ctrl-Break, etc events : http://msdn.microsoft.com/en-us/library/ms683242 and register it with the SetConsoleCtrlHandler http://msdn.microsoft.com/en-us/library/ms686016. I inserted this into my code.

Now, when I click the "X" on the CMDline window that opens when FSUIPC starts my program, my programm catches a Ctrl-Close event, does the cleanup work and exits. Great.

But when I shutdown FS, FSUIPC won't close the Console window it opened.

So in summary: If i click the Console window to Close, it works okay, but apparently FSUIPC does something different.

How do you know which window to send the WM_Close message to? I assume you use the FindWindow method to locate the application you spawned. Then perhaps this problem might be related to obtaining the right HWND for the console: http://support.microsoft.com/kb/124103/

Philipp

[Pete Dowson]

So in summary: If i click the Console window to Close, it works okay, but apparently FSUIPC does something different.

I did explain what it does -- it sends a WM_CLOSE message to the process's main or only Window handle. The problem is presumably that you don't have a Window.

How do you know which window to send the WM_Close message to? I assume you use the FindWindow method to locate the application you spawned. Then perhaps this problem might be related to obtaining the right HWND for the console: http://support.microsoft.com/kb/124103/

Does a console have an HWND?

The method used is to keep the thread ID from when the process was created, then, when it comes time to close, to enumerate the thread windows (EnumThreadWindows), sending a WM_CLOSE message to all top-level Windows thus enumerated. This method has worked without problems reported for twelve years now.

If you know of some way for me to get you the signal you need, please tell me and I'll add this to the CLOSE actions in FSUIPC (and WideClient). The most likely thing I've come up with so far is:

GenerateConsoleCtrlEvent(dwCtrlEvent, dwProcessGroupId);

It looks like this can send either a CTRL_C_EVENT or a CTRL_BREAK_EVENT. To get a Process Group ID I'd need to set the CREATE_NEW_PROCESS_GROUP flag in the CreateProcess call.

Do you want me to try this for you? If you think it might work I can add it to an interim version of FSUIPC (FSUIPC3 or FSUIPC4?) for you to test. Note that you can ignore Ctrl-C but not Ctrl-break, but which one do you need? Or both, one after the other?

Regards

Pete

[PhilippM]

Hi Pete,

wow, I appreciate your offer to enhance FSUIPC just for me :)

But I just managed to create an invisible window that catches your close message and it WORKS!

So I consider this problem solved now.

Thanks for your help!

Philipp

[Pete Dowson]

But I just managed to create an invisible window that catches your close message and it WORKS!

So I consider this problem solved now.

Okay. just as well. It seems that if I use the CREATE_NEW_PROCESS_GROUP flag, it disables CTRL-C signals to your process. I'd still be able to send Ctrl-Break though.

Regards

Pete