Using SetConsoleCtrlHandler
in [Win32 Kernel]
|
Prev: Hook chain using TEB->Win32ThreadInfo
Next: HOMEDRIVE, HOMEPATH missing in CreateEnvironmentBlock
From: Marc Sherman on 7 Jun 2007 09:19 From "Windows Internals, 4th Edition" (p. 108) "The POSIX subsystem uses kernel-mode APCs to emulate the delivery of POSIX signals to POSIX processes". Also from the same page: "Kernel mode APCs interrupt a thread and execute a procedure without the thread's intervention or consent". That tells me they would behave like a UNIX developer would expect. Marc "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in message news:eEO3XfOqHHA.3296(a)TK2MSFTNGP03.phx.gbl... > ...actually, I don't suppose anyone knows how things like SIGINT are > implemented in the POSIX sub-system under Windows. Do they even work like > a > UNIX developer would expect? > > Tony Proctor > > "Gary Chanson" <gchanson(a)No.Spam.mvps.org> wrote in message > news:O$s$jsDqHHA.4132(a)TK2MSFTNGP02.phx.gbl... >> 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(a)aimtechnology_NoMoreSPAM_.com> wrote in > message >> news:eFnX5$BqHHA.1148(a)TK2MSFTNGP06.phx.gbl... >> > 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 ){ } >> > > } >> > >> > >> >> > >
From: Tony Proctor on 7 Jun 2007 10:29 Thanks Marc. That's actually very enlightening Tony Proctor "Marc Sherman" <masherman1970(a)yahoo.com> wrote in message news:O1XaNaQqHHA.4520(a)TK2MSFTNGP04.phx.gbl... > From "Windows Internals, 4th Edition" (p. 108) > > "The POSIX subsystem uses kernel-mode APCs to emulate the delivery of POSIX > signals to POSIX processes". > > Also from the same page: > > "Kernel mode APCs interrupt a thread and execute a procedure without the > thread's intervention or consent". > > That tells me they would behave like a UNIX developer would expect. > > Marc > > "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in message > news:eEO3XfOqHHA.3296(a)TK2MSFTNGP03.phx.gbl... > > ...actually, I don't suppose anyone knows how things like SIGINT are > > implemented in the POSIX sub-system under Windows. Do they even work like > > a > > UNIX developer would expect? > > > > Tony Proctor > > > > "Gary Chanson" <gchanson(a)No.Spam.mvps.org> wrote in message > > news:O$s$jsDqHHA.4132(a)TK2MSFTNGP02.phx.gbl... > >> 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(a)aimtechnology_NoMoreSPAM_.com> wrote in > > message > >> news:eFnX5$BqHHA.1148(a)TK2MSFTNGP06.phx.gbl... > >> > 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 ){ } > >> > > } > >> > > >> > > >> > >> > > > > > >
From: Alexander Grigoriev on 7 Jun 2007 11:46 A BIG BIG problem with asynchronous notifications is that in a multithreaded process there is NO reliable interrupt point, other than explicitly provided (alertable wait). Only a single-threaded POSIX application can be interrupted at a random instruction without ill effects. "Marc Sherman" <masherman1970(a)yahoo.com> wrote in message news:O1XaNaQqHHA.4520(a)TK2MSFTNGP04.phx.gbl... > From "Windows Internals, 4th Edition" (p. 108) > > "The POSIX subsystem uses kernel-mode APCs to emulate the delivery of > POSIX signals to POSIX processes". > > Also from the same page: > > "Kernel mode APCs interrupt a thread and execute a procedure without the > thread's intervention or consent". > > That tells me they would behave like a UNIX developer would expect. > > Marc > > "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in > message news:eEO3XfOqHHA.3296(a)TK2MSFTNGP03.phx.gbl... >> ...actually, I don't suppose anyone knows how things like SIGINT are >> implemented in the POSIX sub-system under Windows. Do they even work like >> a >> UNIX developer would expect? >> >> Tony Proctor >> >> "Gary Chanson" <gchanson(a)No.Spam.mvps.org> wrote in message >> news:O$s$jsDqHHA.4132(a)TK2MSFTNGP02.phx.gbl... >>> 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(a)aimtechnology_NoMoreSPAM_.com> wrote in >> message >>> news:eFnX5$BqHHA.1148(a)TK2MSFTNGP06.phx.gbl... >>> > 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 ){ } >>> > > } >>> > >>> > >>> >>> >> >> > >
From: Gary Chanson on 7 Jun 2007 11:53 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(a)aimtechnology_NoMoreSPAM_.com> wrote in message news:uYNQmeOqHHA.1212(a)TK2MSFTNGP05.phx.gbl... > 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(a)No.Spam.mvps.org> wrote in message > news:O$s$jsDqHHA.4132(a)TK2MSFTNGP02.phx.gbl... > > 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(a)aimtechnology_NoMoreSPAM_.com> wrote in > message > > news:eFnX5$BqHHA.1148(a)TK2MSFTNGP06.phx.gbl... > > > 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 ){ } > > > > } > > > > > > > > > > > >
From: Tony Proctor on 7 Jun 2007 12:08
I see what you're saying Alexander, but it must depend to some extent on how closely interacting those threads are. For instance, an STA architecture wouldn't be nearly as sensitive as a close-knit MTA one Tony Proctor "Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message news:u0k46rRqHHA.1208(a)TK2MSFTNGP02.phx.gbl... > A BIG BIG problem with asynchronous notifications is that in a multithreaded > process there is NO reliable interrupt point, other than explicitly provided > (alertable wait). Only a single-threaded POSIX application can be > interrupted at a random instruction without ill effects. > > "Marc Sherman" <masherman1970(a)yahoo.com> wrote in message > news:O1XaNaQqHHA.4520(a)TK2MSFTNGP04.phx.gbl... > > From "Windows Internals, 4th Edition" (p. 108) > > > > "The POSIX subsystem uses kernel-mode APCs to emulate the delivery of > > POSIX signals to POSIX processes". > > > > Also from the same page: > > > > "Kernel mode APCs interrupt a thread and execute a procedure without the > > thread's intervention or consent". > > > > That tells me they would behave like a UNIX developer would expect. > > > > Marc > > > > "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in > > message news:eEO3XfOqHHA.3296(a)TK2MSFTNGP03.phx.gbl... > >> ...actually, I don't suppose anyone knows how things like SIGINT are > >> implemented in the POSIX sub-system under Windows. Do they even work like > >> a > >> UNIX developer would expect? > >> > >> Tony Proctor > >> > >> "Gary Chanson" <gchanson(a)No.Spam.mvps.org> wrote in message > >> news:O$s$jsDqHHA.4132(a)TK2MSFTNGP02.phx.gbl... > >>> 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(a)aimtechnology_NoMoreSPAM_.com> wrote in > >> message > >>> news:eFnX5$BqHHA.1148(a)TK2MSFTNGP06.phx.gbl... > >>> > 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 ){ } > >>> > > } > >>> > > >>> > > >>> > >>> > >> > >> > > > > > > |