From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1769 invoked by alias); 25 Nov 2007 18:13:23 -0000 Received: (qmail 1757 invoked by uid 22791); 25 Nov 2007 18:13:22 -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; Sun, 25 Nov 2007 18:13:18 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id C1FD52B352; Sun, 25 Nov 2007 13:13:16 -0500 (EST) Date: Sun, 25 Nov 2007 18:13:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: [win32] Fix suspend count handling Message-ID: <20071125181316.GB7689@ednor.casa.cgf.cx> Mail-Followup-To: 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> <20071124204828.GB4928@ednor.casa.cgf.cx> <47498A4F.3050101@champenstudios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47498A4F.3050101@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/msg00468.txt.bz2 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