Re: Using SetConsoleCtrlHandler

"... you would pretty much be limited to something like setting
a flag in a global variable and resuming execution."

Agreed. In another post in this thread, I mentioned either setting a global
or an event as the most that should be done. I think I'll pare that down to
just setting a global because who knows what setting an event (or signalling
a posix conditional variable) does under the covers.

"Skywing [MVP]" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:eirOTkSqHHA.4280@xxxxxxxxxxxxxxxxxxxxxxx
Yes, although with the proposed implementation, the restrictions are
extremely severe:

- No critical sections can be acquired as they do not support interruption
in the acquisition process and will break recursive acquire support

Because it is virtually impossible to do much of anything in Win32 without
doing one of those (for instance, SEH dispatching acquires a critical
section, any dll that hits the loader lock acquires a critical section,
any dll that allocates heap memory acquires a critical section, ... how
many APIs can you think of that do useful work and are guaranteed to never
do one of those tasks), you would pretty much be limited to something like
setting a flag in a global variable and resuming execution.

Since you cannot predict what critical sections an interrupted code
fragment might have acquired or be attempting to acquire, you must assume
that ALL critical sections in the process are off limits. There are of
course other problems besides critical sections, but they are probably one
of the first big difficult-to-cope-with problems that may crop up if you
are not extraordinarily careful and conservative in what you do.

--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"Marc Sherman" <masherman1970@xxxxxxxxx> wrote in message
news:%23TYSfbSqHHA.3484@xxxxxxxxxxxxxxxxxxxxxxx
From my Solaris days, IIRC, you're supposed to do the bare minimum in a
signal handler. Kind of like win32's DllMain restrictions. Sticking to
the "bare minimum" principal should work even in multithreaded POSIX
apps, I believe.

"Skywing [MVP]" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:e%23ZmnBSqHHA.3296@xxxxxxxxxxxxxxxxxxxxxxx
You may still have problems with stuff like the process heap lock.
Furthermore, I think you are still in danger even on a single threaded
system. From taking a quick look at the way the critical section
acquisition code works, it looks like if you interrupt
RtlEnterCriticalSection at the right place, you'll have the CS in an
intermediate state where it's owned but which thread owns it is not
established, such that recursive acqusition doesn't work. That means
you might be in for some trouble (race conditions resulting in a
deadlock) if you rely on recursive lock acqusition in your "signal
handler" - hard to avoid if you call anything that touches the process
heap.

Specifically, consider the tail end of the successful acquire path on
RtlEnterCriticalSection:

ntdll!RtlEnterCriticalSection+0x11:
00000000`76e52685 65488b042530000000 mov rax,qword ptr gs:[30h]
00000000`76e5268e 488b4848 mov rcx,qword ptr [rax+48h]
00000000`76e52692 c7420c01000000 mov dword ptr [rdx+0Ch],1
00000000`76e52699 33c0 xor eax,eax
00000000`76e5269b 48894a10 mov qword ptr [rdx+10h],rcx
00000000`76e5269f 4883c420 add rsp,20h
00000000`76e526a3 5b pop rbx
00000000`76e526a4 c3 ret

If you suspend the thread at rip=00000000`76e52685 in this case, and
then alter context to something that tries to re-enter the same critical
section (say this is the process heap), the recursive acquire will
deadlock in RtlpWaitOnCriticalSection because the first acquire didn't
get around to marking the current thread as the owner of the critical
section.

(in that case, you might see a stack like this:)

0:000> k
Child-SP RetAddr Call Site
00000000`0012fde8 00000000`76e4efc8 ntdll!NtWaitForSingleObject+0xa
00000000`0012fdf0 00000000`76e4ee8b ntdll!RtlpWaitOnCriticalSection+0xd8
00000000`0012fea0 00000000`010018ef ntdll!RtlEnterCriticalSection+0xf4


--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:O7u2I4RqHHA.4536@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx> wrote in message
news:u0k46rRqHHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx> wrote in message
news:O1XaNaQqHHA.4520@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:eEO3XfOqHHA.3296@xxxxxxxxxxxxxxxxxxxxxxx
...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@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 ){ }
}


















.

Relevant Pages

  • Re: Using SetConsoleCtrlHandler
    ... you rely on recursive lock acqusition in your "signal handler" - hard to ... POSIX signals to POSIX processes". ... "Kernel mode APCs interrupt a thread and execute a procedure without ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Using SetConsoleCtrlHandler
    ... "bare minimum" principal should work even in multithreaded POSIX apps, ... you rely on recursive lock acqusition in your "signal handler" - hard to ... POSIX signals to POSIX processes". ... "Kernel mode APCs interrupt a thread and execute a procedure without ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Using SetConsoleCtrlHandler
    ... Only a single-threaded POSIX application can be ... POSIX signals to POSIX processes". ... "Kernel mode APCs interrupt a thread and execute a procedure without the ... void handler { ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Using SetConsoleCtrlHandler
    ... Assuming the signal handler does the minimum (ie. set a global, ... Only a single-threaded POSIX ... POSIX signals to POSIX processes". ... "Kernel mode APCs interrupt a thread and execute a procedure without the ...
    (microsoft.public.win32.programmer.kernel)
  • Re: is it possible to implement condition variables using mutex and/or semaphore?
    ... thread can't be "woken up" by concurrent signalling. ... A thread that returns ETIMEDOUT may have been internally unblocked by ... internally implemented as a wakeup does not meet the POSIX ...
    (comp.programming.threads)
Loading