Signals and Ice::Application

in Help Center
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
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
0
Comments
Anyway, thanks for such a speedy reply,
John
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.