Archived

This forum has been archived. Please start a new discussion on GitHub.

Signals and Ice::Application

I have an application that uses the Ice::Application class. Application does some nice signal handeling through the use of the IceUtil::CtrlCHandler class. This signal handleing class uses a signal handling thread, and does a lot of good things to help clean up ICE upon shutdown.

My application also is creating many other threads. They are not ICE threads. Most of our application is based on Qt, so we are using QThreads. I'm assuming that these QThreads are inheriting the same set of CTRL+C like signals being blocked, since the CtrlCHandler blocks these CTRL+C like signals in its constructor.

My problem is that when an asynscronous CTRL+C like signal is sent to my app, the ICE subsystem shuts down just fine, but my other Qt threads are still running. I guess this makes sense since they have blocked (by default) all of the CTRL+C like signals.

Should I just not use the Ice::Application class, and do my own signal handling thread, or is there something else that I can do to get my threads to terminate properly?

Thanks,
John Marks

Comments

  • Thanks Michi, I'll start ripping out Ice::Application and create my own signal handler thread. Too bad since the Application class does other stuff that is useful (e.g.: ICE exception handlers, initializes the communicator, parses input arguments, etc.).

    Anyway, thanks for such a speedy reply,
    John
  • Actually, I was a bit hasty in replying and deleted my post only a few minutes after I sent it. But, obviously, you managed to spot it before I deleted it ;)

    I think you can actually use Ice::Application, as long as you have only a single communicator. You can probably do all the cleanup you need to do in run(), after communicator()->waitForShutdown() returns.

    This may get you off the hook without having to write your own signal handler from scratch.

    My apologies for misleading you earlier -- I wasn't thinking straight :(

    Cheers,

    Michi.