Prev: Hook chain using TEB->Win32ThreadInfo
Next: HOMEDRIVE, HOMEPATH missing in CreateEnvironmentBlock
From: Emmanuel Stapf [ES] on 5 Jun 2007 21:18
Hi,

I've a console single threaded application and I'm trying to catch a Ctrl+C. No
matter if I use SetConsoleCtrlHandler or a signal handler, my code to handle
this gets called in another thread. Is there a way to have the handler called
from the main thread?

In the code below, simply comment the call to `signal' or to
`SetConsoleCtrlHandler' to observe the similar behavior. On Unix, using
`signal', it is called from the same thread.

Thanks for any highlight,
Manu

PS: this is shown by the code:

#include <windows.h>
#include <stdio.h>
#include <signal.h>

BOOL CtrlHandler( DWORD fdwCtrlType )
{
switch( fdwCtrlType ) {
case CTRL_C_EVENT:
printf( "Ctrl-C event\n\n" );
return TRUE;
default:
return FALSE;
}
}

void handler (int sig) {
printf ("From Signal\n");
signal (SIGINT, handler);
}

void main( void )
{
signal (SIGINT, handler);
//SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE );

printf("Use Ctrl+C to see what is going on.\n" );
while( 1 ){ }
}
From: Gary Chanson on 5 Jun 2007 22:04
What you see is what you get. ;)

How about creating an event which you can signal from your
ConsoleCtrlHandler and detect in your main thread?

--

- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools



"Emmanuel Stapf [ES]" <manus(a)newsgroups.nospam> wrote in message
news:uQhAUi9pHHA.1144(a)TK2MSFTNGP02.phx.gbl...
> Hi,
>
> I've a console single threaded application and I'm trying to catch a
Ctrl+C. No
> matter if I use SetConsoleCtrlHandler or a signal handler, my code to
handle
> this gets called in another thread. Is there a way to have the handler
called
> from the main thread?
>
> In the code below, simply comment the call to `signal' or to
> `SetConsoleCtrlHandler' to observe the similar behavior. On Unix, using
> `signal', it is called from the same thread.
>
> Thanks for any highlight,
> Manu
>
> PS: this is shown by the code:
>
> #include <windows.h>
> #include <stdio.h>
> #include <signal.h>
>
> BOOL CtrlHandler( DWORD fdwCtrlType )
> {
> switch( fdwCtrlType ) {
> case CTRL_C_EVENT:
> printf( "Ctrl-C event\n\n" );
> return TRUE;
> default:
> return FALSE;
> }
> }
>
> void handler (int sig) {
> printf ("From Signal\n");
> signal (SIGINT, handler);
> }
>
> void main( void )
> {
> signal (SIGINT, handler);
> //SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE );
>
> printf("Use Ctrl+C to see what is going on.\n" );
> while( 1 ){ }
> }


From: Emmanuel Stapf [ES] on 5 Jun 2007 22:41
Gary Chanson wrote:
> What you see is what you get. ;)
>
> How about creating an event which you can signal from your
> ConsoleCtrlHandler and detect in your main thread?

In my case, I'm building a framework for the Eiffel language
(http://dev.eiffel.com) and I need a simple way to ensure that Ctrl+C is
translated into an exception in the current thread without having to inject too
much code that could slow down the normal execution.

So it would be nice if there was an alternative.

Regards,
Manu
From: "Jeffrey Tan[MSFT]" on 6 Jun 2007 04:46
Hi Emmanuel ,

I do not think Windows has exposed any interface for configuring this. As I
dig into the code, this behavior is by design. After the OS captured the
Ctrl+C interrupt, it will initiate a user-mode APC to schedule another
thread to call Kernel32!CtrlRoutine function, which finally calls your
registered "CtrlHandler".

Based on my knowledge, this type of asynchronous callback in Windows
normally comes in 2 forms:
1. Windows created a second thread to call the callback function.
2. Main thread in the application calls certain type of Wait*** functions
in a loop to retrieve the asynchronous notification. (This is because, the
callback notification can not interrupt the main thread without at a safe
point. ). I/O completion port uses this form

Since there is not guarantee that the console application main thread will
alway have a loop to call Wait*** functions, console handler uses the first
form.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

From: Tony Proctor on 6 Jun 2007 05:49
Windows is not very good at handling this sort of asynchronous interrupt on
a single thread Emmanuel (i.e. similar to UNIX signals, or even VMS ASTs)

The question has been asked before:
http://groups.google.ie/group/microsoft.public.win32.programmer.kernel/browse_frm/thread/608ad10204f76515/1e175f06dca6106f?hl=en#1e175f06dca6106f

I've even found myself in the same boat in trying to port a language, and
its framework, to the Windows O/S. In the end, I suspended the thread, read
its context, redirected it to a point that would generate the required
exception, and then released it. Surprisingly, it worked OK in practice
(although not on Alpha AXP H/W) but there were a few issues with win32 api
calls that had to be addressed (mentioned in that old thread)

Tony Proctor

"Emmanuel Stapf [ES]" <manus(a)newsgroups.nospam> wrote in message
news:uQhAUi9pHHA.1144(a)TK2MSFTNGP02.phx.gbl...
> Hi,
>
> I've a console single threaded application and I'm trying to catch a
Ctrl+C. No
> matter if I use SetConsoleCtrlHandler or a signal handler, my code to
handle
> this gets called in another thread. Is there a way to have the handler
called
> from the main thread?
>
> In the code below, simply comment the call to `signal' or to
> `SetConsoleCtrlHandler' to observe the similar behavior. On Unix, using
> `signal', it is called from the same thread.
>
> Thanks for any highlight,
> Manu
>
> PS: this is shown by the code:
>
> #include <windows.h>
> #include <stdio.h>
> #include <signal.h>
>
> BOOL CtrlHandler( DWORD fdwCtrlType )
> {
> switch( fdwCtrlType ) {
> case CTRL_C_EVENT:
> printf( "Ctrl-C event\n\n" );
> return TRUE;
> default:
> return FALSE;
> }
> }
>
> void handler (int sig) {
> printf ("From Signal\n");
> signal (SIGINT, handler);
> }
>
> void main( void )
> {
> signal (SIGINT, handler);
> //SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE );
>
> printf("Use Ctrl+C to see what is going on.\n" );
> while( 1 ){ }
> }


 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Hook chain using TEB->Win32ThreadInfo
Next: HOMEDRIVE, HOMEPATH missing in CreateEnvironmentBlock