- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a console application that uses OpenMP and IPP, and it gets spawned by another Windows process that runs as a service. This setup is running on a server that admins occasionally log onto and log off of using a Remote Desktop.
I noticed that during log off, no matter what user, my IPP-enabled application gets killed. I narrowed down the problem to linking with the IPP libraries. When linked with IPP, logoff results in my process exiting. Without IPP, the process continues normally.
I just came across a Windows API call, SetConsoleCtrlHandler, described here:
http://msdn.microsoft.com/en-us/library/ms686016%28VS.85%29.aspx
and the handler routines here:
http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx
If I include in one of my application DLLs a handler routine that catches CTRL_LOGOFF_EVENT and throws it away, the problem goes away. Users can log in and out at will and my IPP-enabled application keeps running.
So this seems like a good solution, but I'm wondering why it's necessary. By "throw it away" my handler basically prevents other handlers registered with SetConsoleCtrlHandler from executing. Is this a bad idea? Why does IPP even register a handler using SetConsoleCtrlHandler? Some of the IPP DLLs (libguide40.dll, possibly others) import SetConsoleCtrlHandler and ExitProcess from kernel32.dll. Is there a reason for this?
I'd really like to see the IPP source code that calls SetConsoleCtrlHandler, but that may be asking a lot. Has anyone else ever come across this problem?
I noticed that during log off, no matter what user, my IPP-enabled application gets killed. I narrowed down the problem to linking with the IPP libraries. When linked with IPP, logoff results in my process exiting. Without IPP, the process continues normally.
I just came across a Windows API call, SetConsoleCtrlHandler, described here:
http://msdn.microsoft.com/en-us/library/ms686016%28VS.85%29.aspx
and the handler routines here:
http://msdn.microsoft.com/en-us/library/ms683242%28VS.85%29.aspx
If I include in one of my application DLLs a handler routine that catches CTRL_LOGOFF_EVENT and throws it away, the problem goes away. Users can log in and out at will and my IPP-enabled application keeps running.
So this seems like a good solution, but I'm wondering why it's necessary. By "throw it away" my handler basically prevents other handlers registered with SetConsoleCtrlHandler from executing. Is this a bad idea? Why does IPP even register a handler using SetConsoleCtrlHandler? Some of the IPP DLLs (libguide40.dll, possibly others) import SetConsoleCtrlHandler and ExitProcess from kernel32.dll. Is there a reason for this?
I'd really like to see the IPP source code that calls SetConsoleCtrlHandler, but that may be asking a lot. Has anyone else ever come across this problem?
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe the OpenMP library has some console output elements that are used for information and debugging, which might be the reason for needing the SetConsoleCtrlHandler. Unfortunately, the folks who could answer this question are gone through the end of the year, due to the holidays, so a confirmation of that theory will take a while.
In the meantime, you might try building your IPP application using the static single-threaded version of the library, which does not include the OpenMP library, to see if changes the behavior.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page