From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5261 invoked by alias); 24 Nov 2007 15:49:22 -0000 Received: (qmail 5251 invoked by uid 22791); 24 Nov 2007 15:49:20 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Nov 2007 15:49:10 +0000 Received: by nf-out-0910.google.com with SMTP id b11so138736nfh for ; Sat, 24 Nov 2007 07:49:08 -0800 (PST) Received: by 10.86.25.17 with SMTP id 17mr614988fgy.1195919348062; Sat, 24 Nov 2007 07:49:08 -0800 (PST) Received: from ?192.168.1.115? ( [195.23.205.143]) by mx.google.com with ESMTPS id l12sm1863484fgb.2007.11.24.07.49.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Nov 2007 07:49:07 -0800 (PST) Message-ID: <474847F1.3090301@portugalmail.pt> Date: Sat, 24 Nov 2007 15:49:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Lerele 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> In-Reply-To: <474832C2.7030307@champenstudios.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00453.txt.bz2 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. -- Pedro Alves