From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20323 invoked by alias); 24 Nov 2007 17:50:55 -0000 Received: (qmail 20313 invoked by uid 22791); 24 Nov 2007 17:50:54 -0000 X-Spam-Check-By: sourceware.org Received: from gw.sprintaddict.net (HELO champenstudios.com) (80.91.89.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Nov 2007 17:50:45 +0000 Received: from [192.168.1.5] (164.Red-80-36-45.staticIP.rima-tde.net [80.36.45.164]) (authenticated bits=0) by champenstudios.com (8.13.8/8.13.8) with ESMTP id lAOHh7Ap032350 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2007 18:43:08 +0100 Message-ID: <4748646F.1090208@champenstudios.com> Date: Sat, 24 Nov 2007 17:50:00 -0000 From: Lerele User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: [win32] Fix suspend count handling References: <47437D3A.3000107@portugalmail.pt> <000001c82c31$4a57b220$df071660$@u-strasbg.fr> <4053daab0711210543w4b241e1ek2371e887f3c4f7d2@mail.gmail.com> <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> In-Reply-To: <474847F1.3090301@portugalmail.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: 2007-11/txt/msg00455.txt.bz2 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.