Re: Using SetConsoleCtrlHandler

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

As I said, in my case, I could make the assumption that the thread would
be in an alertable state often enough. One way of assuring that is to call
SleepEx(...,TRUE) fairly often.

--

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



"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uYNQmeOqHHA.1212@xxxxxxxxxxxxxxxxxxxxxxx
The difference there is the fact that the code must be in an alertable
state
Gary. There are several possible mechanisms for an event-driven
client-side
application but if it's server-side then this requirement makes the
"interrupt" less than responsive. In my case, the code was being ported
from
elsewhere and wasn't event-driven (in the Windows sense) or even had a
message pump.

I admit to not having used APCs though. If the APC queue were examined
when
a thread starts executing (i.e. after leaving a wait state, or being taken
off the ready-to-run queue) then it would be ideal, but I don't believe
it's
implemented at that level

Tony Proctor

"Gary Chanson" <gchanson@xxxxxxxxxxxxxxxx> wrote in message
news:O$s$jsDqHHA.4132@xxxxxxxxxxxxxxxxxxxxxxx
My solution for a similar situation was to redirect the exception to
the
appropriate thread using a User APC. In my case, I can be reasonably
certain that the task will enter an alertable state within a reasonable
time, so this works very nicely and is a lot cleaner they your
alternative.

--

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



"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:eFnX5$BqHHA.1148@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxx> wrote in message
news:uQhAUi9pHHA.1144@xxxxxxxxxxxxxxxxxxxxxxx
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 ){ }
}








.