Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Does QCoreApplication create it's own unix SIGINT handlers? If yes, how can I tell it not to?
Forum Update on Monday, May 27th 2025

Does QCoreApplication create it's own unix SIGINT handlers? If yes, how can I tell it not to?

Scheduled Pinned Locked Moved Unsolved General and Desktop
6 Posts 3 Posters 812 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • I Offline
    I Offline
    IliasElk
    wrote on 10 Feb 2021, 10:42 last edited by IliasElk 2 Oct 2021, 10:44
    #1

    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...).

    J 1 Reply Last reply 10 Feb 2021, 12:08
    0
    • I IliasElk
      10 Feb 2021, 10:42

      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...).

      J Offline
      J Offline
      jsulm
      Lifetime Qt Champion
      wrote on 10 Feb 2021, 12:08 last edited by
      #2

      @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()?

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      I 1 Reply Last reply 10 Feb 2021, 12:16
      0
      • J jsulm
        10 Feb 2021, 12:08

        @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()?

        I Offline
        I Offline
        IliasElk
        wrote on 10 Feb 2021, 12:16 last edited by IliasElk 2 Oct 2021, 12:31
        #3

        @jsulm

        Hi, 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.

        1 Reply Last reply
        0
        • I Offline
          I Offline
          IliasElk
          wrote on 10 Feb 2021, 13:14 last edited by IliasElk 2 Oct 2021, 13:34
          #4
          This post is deleted!
          1 Reply Last reply
          0
          • K Offline
            K Offline
            Kent-Dorfman
            wrote on 11 Feb 2021, 05:45 last edited by
            #5

            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.

            I 1 Reply Last reply 11 Feb 2021, 13:07
            0
            • K Kent-Dorfman
              11 Feb 2021, 05:45

              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.

              I Offline
              I Offline
              IliasElk
              wrote on 11 Feb 2021, 13:07 last edited by IliasElk 2 Nov 2021, 13:08
              #6

              @Kent-Dorfman

              Thank 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 Reply Last reply
              0

              1/6

              10 Feb 2021, 10:42

              • Login

              • Login or register to search.
              1 out of 6
              • First post
                1/6
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved