Does QCoreApplication create it's own unix SIGINT handlers? If yes, how can I tell it not to?
-
wrote on 10 Feb 2021, 10:42 last edited by IliasElk 2 Oct 2021, 10:44
Hi!
I have a main unix application, which loads a plugin I've written, that is ported from a QT application and thus contains a QCoreApplication instance.
In my main application I register a SIGINT handler like so:
void sigint_handler([[maybe_unused]] int sig) { // Tell software to exit correctly... } ... int main(int argc, char* argv[]) { signal(SIGINT, sigint_handler); ... // ... wait until flag is set in sigint_handler. }
When loading any other plugin, sigint_handler is called correctly.
But when loading the plugin in which I instantiate and exec() a QCoreApplication, sigint_handler is never called on SIGINT!
My suspicion is that QCoreApplication registers its own SIGINT handler, replacing mine, but I have found no documentation stating this for QT.
Can anyone tell me for sure? Does QCoreApplication create it's own unix SIGINT handlers?
If yes, how can I tell it not to?
Thank you!
And just in case, to clear any confusion: above, I always refer to UNIX signals, eg SIGINT - not QT signals (and slots...).
-
Hi!
I have a main unix application, which loads a plugin I've written, that is ported from a QT application and thus contains a QCoreApplication instance.
In my main application I register a SIGINT handler like so:
void sigint_handler([[maybe_unused]] int sig) { // Tell software to exit correctly... } ... int main(int argc, char* argv[]) { signal(SIGINT, sigint_handler); ... // ... wait until flag is set in sigint_handler. }
When loading any other plugin, sigint_handler is called correctly.
But when loading the plugin in which I instantiate and exec() a QCoreApplication, sigint_handler is never called on SIGINT!
My suspicion is that QCoreApplication registers its own SIGINT handler, replacing mine, but I have found no documentation stating this for QT.
Can anyone tell me for sure? Does QCoreApplication create it's own unix SIGINT handlers?
If yes, how can I tell it not to?
Thank you!
And just in case, to clear any confusion: above, I always refer to UNIX signals, eg SIGINT - not QT signals (and slots...).
@IliasElk said in Does QCoreApplication create it's own unix SIGINT handlers? If yes, how can I tell it not to?:
signal(SIGINT, sigint_handler);
Do you call this before loading the plug-in and calling QCoreApplication::exec()?
-
@IliasElk said in Does QCoreApplication create it's own unix SIGINT handlers? If yes, how can I tell it not to?:
signal(SIGINT, sigint_handler);
Do you call this before loading the plug-in and calling QCoreApplication::exec()?
wrote on 10 Feb 2021, 12:16 last edited by IliasElk 2 Oct 2021, 12:31Hi, yes, that's called in my main application's constructor.
That's necessary, since the application can be interrupted at any time before the plugin itself is loaded - the plugin can be loaded at any time during execution.
The plugin API is a general one - VST2 - meaning the plugin should be loadable in any host.
I could just re-set all handlers after any plugin loading, but that's a bad design I'd rather avoid, and it wouldn't address the issue if the plugin is loaded in a different host.
I am now experimenting with fetching and re-setting the signal handler function pointer within my plugin, so that the host does not have to treat it any differently.
But the clean solution would still be to be able to tell QCoreApplication to leave the handlers be to begin with, so my question would stand regardless.
-
wrote on 10 Feb 2021, 13:14 last edited by IliasElk 2 Oct 2021, 13:34This post is deleted!
-
wrote on 11 Feb 2021, 05:45 last edited by
OP. You are most probably correct. It would be common for a framework like Qt to intercept signals...which is why you may find it useful to avoid the traditional signal() call and implement your signal handlers as a chain of handlers using sigaction() instead.
-
OP. You are most probably correct. It would be common for a framework like Qt to intercept signals...which is why you may find it useful to avoid the traditional signal() call and implement your signal handlers as a chain of handlers using sigaction() instead.
wrote on 11 Feb 2021, 13:07 last edited by IliasElk 2 Nov 2021, 13:08Thank you!
For my own host that would be a solution, but I cannot know that other hosts do the same.
The VST standard is widespread, with very many host applications available on the market.
And as the plugin I am using QT in should be compatible with any host, I would still love a way to tell it to not intercept those - a non-QT plugin mode if you will.
1/6