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

[Pedro Alves <pedro at codesourcery dot com>]

A Tuesday 24 June 2008 02:13:37, Christopher Faylor wrote:

> Which is not me.

I know.  I really didn't mean to imply you were one of them.

> If you want gdb to be usable on systems other than Windows XP and beyond
> then you can't use SuspendThread.
>
> I'm not speaking from theory.  I'm speaking from experience.

As I said, I know you have been all over this before.  I'm not
trying to be picky on you.  :-)

Wasn't the conclusion that calling GetThreadContext blocks
until the thread really suspends, or that GetThreadContext fails
if the thread hasn't suspend yet?  Like here:

http://cygwin.com/ml/cygwin-developers/2005-12/msg00005.html

What was the outcome of that?

I really would like to know of a problem it has caused by using
it from a debugger, that is, from a process which isn't the
owner of the thread; instead of a problem caused by calling
SuspendThread on a thread of the current process.

> If this wasn't something that we wanted to do then we shouldn't be
> carefully autoloading functions that only exist in XP in win32-nat.c.

Right, but that's a bit of a different issue.  SuspendThread has
been available in win32 since ever.  DebugBreakProcess hasn't.


I happen to have written a patch last week that implements scheduler
locking for win32-nat.c, that relies on SuspendThread to leave
the other non-resumed threads suspended (the original suspending
is done internally by windows before returning from
WaitForDebugEvent).  I'm hoping that this kind of usage SuspendThread
usage is accepted...

-- 
Pedro Alves