From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22769 invoked by alias); 25 Nov 2007 20:34:42 -0000 Received: (qmail 22761 invoked by uid 22791); 25 Nov 2007 20:34:41 -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; Sun, 25 Nov 2007 20:34:32 +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 lAPKQs90001726 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Nov 2007 21:26:55 +0100 Message-ID: <4749DC53.5090803@champenstudios.com> Date: Sun, 25 Nov 2007 20:34:00 -0000 From: Lerele User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [win32] Fix suspend count handling 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> <20071124204828.GB4928@ednor.casa.cgf.cx> <47498A4F.3050101@champenstudios.com> <20071125181316.GB7689@ednor.casa.cgf.cx> In-Reply-To: <20071125181316.GB7689@ednor.casa.cgf.cx> 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/msg00472.txt.bz2 Christopher Faylor escribió: > On Sun, Nov 25, 2007 at 03:44:31PM +0100, Lerele wrote: > >> What do you think? >> > > There is some code in win32-nat.c which was a result of my uncertainty > about the Windows debugging API. I thought that since we have a couple > more eyes on this now someone might know a bit more about how this > works. Understanding the foundations is never a bad idea. > > I'm not interested in gdbserver or what you think may be happening in > the future. If the SuspendThread/ResumeThread code can be eliminated > from win32-nat.c along with all of the bookkeeping that is required to > avoid races then it may be a good idea to do so. Whether it is a good > idea in light of future enhancements is a decision I can make but, > personally, I rarely see a good reason to keep code complication around > for the future unless someone is actually planning to do the work. > > We can stop talking about this now since it is apparent that no one > actually knows the answer to my question. > > cgf > > Okay. Derived from my previous messages, which by the way I do not really know if you read/undestood, is that for the third time I'm saying SuspendThread I think is safer (as you did think once) and does not really hurt, and it's not such a complication keeping it around, in my opinion. The only problem I see is that a small bug has been detected, that's all. If win32-nat.c is going to give control back to gdb in response to a Win32 debug event only, it's obvious SuspendThread is not needed. When WaitForDebugEvent returns an event, all child threads are stopped, so yes, SuspendThread is *not* needed. Is this the short answer you were looking for??? Also, may you be interested in the fact that currently interrupting a running program using gdb 6.7 does *not* seem to work? Either if you run gdb alone (not gdbserver) or using a front-end? To my point, as gdbserver win32 code is win32-nat.c based, funtionality is very similar. One such functionality could be the latest SuspendThread interruption that has been added to gdbserver (but not to win32-nat.c). As such, could you be interested in this for win32-nat.c? If this functionality is of interest, then that's another reason to keep thread_rec/SuspendThread.