Winelib: SIGTERM or SIGQUIT?
I would like my Winelib application to do a normal shutdown from a signal, that is save files and exit normally.
From scanning the web SIGTERM seems like the natural choice. It looks like it is _supposed_ to be used for a normal exit. But Wine seems to reserve SIGTERM for a summary execution with pthread_abort.
It looks like I could use SIGQUIT, since Wine doesn't seem to care about it. But, again from scanning the web, SIGQUIT is _supposed_ to be used for non-normal exits. So, is it best to use SIGQUIT in a non-canonical way or try to change how SIGTERM is handled by Wine and make it more canonical? Or maybe my reading of the "canon of signals" is incorrect? Thanks for any help... mo PS: recently someone was asking a question about winelib and was directed to wine-user. What's the protocol here? Where should winelib questions be asked? The wine-user looks too user level and wine-devel is for Wine coders. I'd appreciate any help with the protocol of all this... =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com
On Tue, 2006-04-18 at 12:12 -0700, Michael Ost wrote:
PS: recently someone was asking a question about winelib and was directed to wine-user. What's the protocol here? Where should winelib questions be asked? The wine-user looks too user level and wine-devel is for Wine coders. I'd appreciate any help with the protocol of all this...
This is the right list. Any development questions (wine or winelib related) belong to wine-devel. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
Michael Ost <most(a)museresearch.com> writes:
I would like my Winelib application to do a normal shutdown from a signal, that is save files and exit normally.
From scanning the web SIGTERM seems like the natural choice. It looks like it is _supposed_ to be used for a normal exit. But Wine seems to reserve SIGTERM for a summary execution with pthread_abort.
It looks like I could use SIGQUIT, since Wine doesn't seem to care about it. But, again from scanning the web, SIGQUIT is _supposed_ to be used for non-normal exits.
So, is it best to use SIGQUIT in a non-canonical way or try to change how SIGTERM is handled by Wine and make it more canonical? Or maybe my reading of the "canon of signals" is incorrect?
SIGTERM in Wine corresponds to TerminateThread, which is the standard way to kill a thread in Win32, so it sounds very much canonical, I don't think you want to change it. You can certainly use SIGQUIT, but if you are defining your own mechanism, using signals is probably not the best choice. Cleaning up properly on a signal is pretty hard to do right, and even harder in Wine since we use signals for our own purposes. -- Alexandre Julliard julliard(a)winehq.org
On Wed, 2006-04-19 at 11:06 +0200, Alexandre Julliard wrote:
You can certainly use SIGQUIT, but if you are defining your own mechanism, using signals is probably not the best choice. Cleaning up properly on a signal is pretty hard to do right, and even harder in Wine since we use signals for our own purposes.
I'll try SIGQUIT, knowing that Wine itself has no intentions of using it any time soon. As far as clean up goes, all I want to do is PostQuitMessage(0). Does this look safe as a SIGQUIT handler? static void exit_handler(int signal) { printf("%s: got exit signal(%d)\n", __FUNCTION__, signal); PostQuitMessage(0); } ... mo
Michael Ost <most(a)museresearch.com> writes:
I'll try SIGQUIT, knowing that Wine itself has no intentions of using it any time soon.
As far as clean up goes, all I want to do is PostQuitMessage(0). Does this look safe as a SIGQUIT handler?
It should be safe, as long as you never run 16-bit code; you also need to add SIGQUIT to the various signal masks in ntdll. But a small Winelib app that sends a WM_QUIT message to the main app is probably a lot easier... -- Alexandre Julliard julliard(a)winehq.org
On Wed, 2006-04-19 at 20:39 +0200, Alexandre Julliard wrote:
Michael Ost <most(a)museresearch.com> writes:
I'll try SIGQUIT, knowing that Wine itself has no intentions of using it any time soon.
As far as clean up goes, all I want to do is PostQuitMessage(0). Does this look safe as a SIGQUIT handler?
It should be safe, as long as you never run 16-bit code; you also need
I'm OK there.
to add SIGQUIT to the various signal masks in ntdll. But a small
Well the signal works without patching ntdll. So I guess that's covered too. Thanks... mo
Michael Ost <most(a)museresearch.com> writes:
to add SIGQUIT to the various signal masks in ntdll. But a small
Well the signal works without patching ntdll. So I guess that's covered too.
If you don't add it to the signal masks, it will work most of the time, and fail dramatically when the signal happens at just the wrong spot. -- Alexandre Julliard julliard(a)winehq.org
On Wed, 2006-04-19 at 21:46 +0200, Alexandre Julliard wrote:
Michael Ost <most(a)museresearch.com> writes:
to add SIGQUIT to the various signal masks in ntdll. But a small
Well the signal works without patching ntdll. So I guess that's covered too.
If you don't add it to the signal masks, it will work most of the time, and fail dramatically when the signal happens at just the wrong spot.
Oh. Thanks for the warning! Maybe saved me hours/days of head scratching.... mo
participants (3)
-
Alexandre Julliard -
Dimi Paun -
Michael Ost