Re: [RFC] win32-nat.c 'set new-console' and interruption

[Pedro Alves <pedro@codesourcery.com>]

A Monday 23 June 2008 18:36:20, Christopher Faylor wrote:
> On Mon, Jun 23, 2008 at 03:41:26PM +0100, Pedro Alves wrote:
> >Another option is to use SuspendThread on all threads to stop the
> >process, which is what I believe Visual Studio uses.  gdbserver has
> >that implemented for systems that don't have DebugBreakProcess.
>
> It may be ok in Windows XP and beyond (I haven't checked) but I don't
> believe you can reliably use SuspendThread otherwise.  If you suspend a
> thread at the wrong point you can cause problems.

It may have been a problem with earlier Windows versions (maybe deadlocking
on some global internal lock, but evidence is scarse).  Not sure it's a
real problem.  Would pretty much make it useless if you can't use it from a
debugger.  google is riddled with articles claiming not to use it, but
those are aimed at application developers who confuse it with a locking
primitive.  I don't believe that when WaitForDebugEvent returns
with all threads stopped, there has been any kind of special magic
done that SuspendThread wouldn't trigger.  Sure, it is dangerous to use 
SuspendThreads to suspend threads in the current process (as
some stack walking libs do), as the deadlock risk is higher
then, like deadlocking on output or painting routines; but that is a
non-issue for a debugger.

I know for sure MSFT's Windows CE debugger (I bet it's the same
codebase as the desktop debugger) uses SuspendThread to stop the process,
as enabling its debug output tells the whole world.  :-)  I did notice
that it was GetThreadContext that seemed to do the blocking
waiting for the thread to suspend in user-code (and noticed other
weirdnesses around that, that seemed CE specific).

I know you've been all over this before, but for the archives:

Quoting from MSDN:
 "If the function succeeds, execution of the specified thread is suspended and  
 the thread's suspend count is incremented. Suspending a thread causes the  
 thread to stop executing *user-mode* (application) code."

 "This function is primarily designed for use by debuggers. It is not intended 
 to be used for thread synchronization. (...)"

I sure hope we can use it if/when we get to implement non-stop mode for
Windows.

Anyway, back to the original issue: do we really need to translate
that SIGTRAP into a SIGINT (from a DebugBreakProcess) ?

-- 
Pedro Alves