Difference between revisions of "Ctrl C"
| Line 2: | Line 2: | ||
On Windows, the handling of SIGINT (aka Ctrl+C for a DOS prompt) is done in a different thread than the running thread. Which means that the current runtime cannot handle it properly without failing, since it throws an exception in the wrong thread. This problem is even more visible in a multithreaded application. | On Windows, the handling of SIGINT (aka Ctrl+C for a DOS prompt) is done in a different thread than the running thread. Which means that the current runtime cannot handle it properly without failing, since it throws an exception in the wrong thread. This problem is even more visible in a multithreaded application. | ||
| − | I've posted a question on the Microsoft newsgroups and here is the [http://groups.google.ie/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/b0bdada7bae7ffa4/e4ea8cd55871b466?tvc=1&hl=en#e4ea8cd55871b466 discussion thread]. The interesting part of this is a reference to [http://groups.google.ie/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/608ad10204f76515/1e175f06dca6106f?hl=en#1e175f06dca6106f another discussion thread] where they propose a solution. | + | I've posted a question on the Microsoft newsgroups and here is the [http://groups.google.ie/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/b0bdada7bae7ffa4/e4ea8cd55871b466?tvc=1&hl=en#e4ea8cd55871b466 discussion thread]. The interesting part of this is a reference to [http://groups.google.ie/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/608ad10204f76515/1e175f06dca6106f?hl=en#1e175f06dca6106f another discussion thread] where they propose a solution. A quick summary is the following code: |
| + | |||
| + | <c> | ||
| + | // Suspend the thread | ||
| + | |||
| + | SuspendThread(hSorryThread); | ||
| + | |||
| + | // Get the thread's suspended context and then | ||
| + | // update it to point to the cleanup routine ... | ||
| + | |||
| + | ctx.ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER; | ||
| + | ctx.Eip = (DWORD) CleanupProc; // You define this | ||
| + | SetThreadContext(hSorryThread, &ctx); | ||
| + | |||
| + | // and resume the thread with the new context | ||
| + | |||
| + | ResumeThread(hSorryThread); | ||
| + | |||
| + | // Note that the sketch above assumes that CleanupProc() takes no arguments and | ||
| + | // will exit the thread. It had better because the few lines above don't do | ||
| + | // anything with the stack. | ||
| + | </c> | ||
This needs to be investigated. | This needs to be investigated. | ||
Revision as of 16:53, 6 June 2007
On Windows, the handling of SIGINT (aka Ctrl+C for a DOS prompt) is done in a different thread than the running thread. Which means that the current runtime cannot handle it properly without failing, since it throws an exception in the wrong thread. This problem is even more visible in a multithreaded application.
I've posted a question on the Microsoft newsgroups and here is the discussion thread. The interesting part of this is a reference to another discussion thread where they propose a solution. A quick summary is the following code:
// Suspend the thread SuspendThread(hSorryThread); // Get the thread's suspended context and then // update it to point to the cleanup routine ... ctx.ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER; ctx.Eip = (DWORD) CleanupProc; // You define this SetThreadContext(hSorryThread, &ctx); // and resume the thread with the new context ResumeThread(hSorryThread); // Note that the sketch above assumes that CleanupProc() takes no arguments and // will exit the thread. It had better because the few lines above don't do // anything with the stack.
This needs to be investigated.
