Prev: Hook chain using TEB->Win32ThreadInfo
Next: HOMEDRIVE, HOMEPATH missing in CreateEnvironmentBlock
From: Skywing [MVP] on 8 Jun 2007 09:57
Yes, but you can break the re-entrant features of some locks (e.g. critical
sections) if you suspend and interrupt the acquire process at the right
time.

--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message
news:OUPrq8XqHHA.3248(a)TK2MSFTNGP03.phx.gbl...
> Any multithreaded process uses locks behind your back, when you call heap
> allocation or stdio functions. You cannot be sure when the locks are not
> held. single-thread process doesn't have to hold any locks, and even if it
> does, the locks are reentrant, so dropping one is not dangerous.
>
> "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in
> message news:O7u2I4RqHHA.4536(a)TK2MSFTNGP05.phx.gbl...
>>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 ){ }
>>> >>> > > }
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>

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