From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6623 invoked by alias); 24 Jun 2008 12:32:05 -0000 Received: (qmail 6613 invoked by uid 22791); 24 Jun 2008 12:32:04 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Jun 2008 12:31:39 +0000 Received: (qmail 28059 invoked from network); 24 Jun 2008 12:31:35 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jun 2008 12:31:35 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] win32-nat.c 'set new-console' and interruption Date: Tue, 24 Jun 2008 13:54:00 -0000 User-Agent: KMail/1.9.9 References: <000001c8d330$0c6b51f0$2541f5d0$@u-strasbg.fr> <200806231922.10798.pedro@codesourcery.com> <20080624011336.GA13397@ednor.casa.cgf.cx> In-Reply-To: <20080624011336.GA13397@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806241331.23092.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00406.txt.bz2 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