From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29638 invoked by alias); 24 Nov 2007 20:49:22 -0000 Received: (qmail 29626 invoked by uid 22791); 24 Nov 2007 20:49:21 -0000 X-Spam-Check-By: sourceware.org Received: from pool-70-20-17-24.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (70.20.17.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Nov 2007 20:49:15 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id E906C2B352; Sat, 24 Nov 2007 15:49:13 -0500 (EST) Date: Sat, 24 Nov 2007 20:49:00 -0000 From: Christopher Faylor To: Lerele , Pedro Alves , gdb-patches@sourceware.org Subject: Re: [win32] Fix suspend count handling Message-ID: <20071124204913.GC4928@ednor.casa.cgf.cx> Mail-Followup-To: Lerele , Pedro Alves , gdb-patches@sourceware.org References: <000401c82c48$a450df10$ecf29d30$@u-strasbg.fr> <4053daab0711210708o607018b9n8b63147a8498a207@mail.gmail.com> <4053daab0711211019r15f3a862g677080b65b4d8e71@mail.gmail.com> <4744BCCE.60705@portugalmail.pt> <20071123010744.GA31180@ednor.casa.cgf.cx> <4746A922.30404@champenstudios.com> <20071124053341.GA4214@ednor.casa.cgf.cx> <474832C2.7030307@champenstudios.com> <474847F1.3090301@portugalmail.pt> <4748646F.1090208@champenstudios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4748646F.1090208@champenstudios.com> User-Agent: Mutt/1.5.16 (2007-06-09) 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: 2007-11/txt/msg00457.txt.bz2 On Sat, Nov 24, 2007 at 06:50:39PM +0100, Lerele wrote: > Pedro Alves escribi?: >> Lerele wrote: >> >> > This paragraph >>> makes me ask, maybe the problems you talk about were due to some other >>> reason, and not just about using SuspendThread only? Or are you 100% sure >>> it's because of that specific function? >>> >> >> Its not the function per se that's the problem. It's that when we >> suspend a thread it may be holding some internal lock, or >> some such. Calling the same function or another function that accesses >> the same internal resources from another thread may violate what >> was expected internally. My experience on porting gdbserver to WinCE, >> showed me that on WinCE at least, SuspendThread will not immediatelly >> suspend the thread -- that probably means that the OS only stops the >> threads on safe points. That a look here [1]. It may be that >> earlier versions of Windows had bugs that made that unsafe. >> (Windows CE source code is available, but I won't touch it with a >> ten-meter [2] pole.) >> >> >> [1] >> http://sourceware.org/ml/gdb-patches/2007-11/msg00220.html >> -- Yes not perfect, I know. >> >> [2] >> I think metric. >> > > It's actually hard to believe those functions do not work as expected, > especially because MSDN docs specifically state using SuspendThread before > GetThreadContext, asuming the latter should work after the former, but of > course anything is possible. > > If that is true, it's useless of course to use them functions. It's possible that GetThreadContext may wait for pending SuspendThread's. cgf