From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9014 invoked by alias); 25 Jun 2008 21:23:40 -0000 Received: (qmail 9006 invoked by uid 22791); 25 Jun 2008 21:23:39 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jun 2008 21:23:21 +0000 Received: (qmail 27809 invoked from network); 25 Jun 2008 21:23:20 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jun 2008 21:23:20 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [non-stop] 08/10 linux native support Date: Wed, 25 Jun 2008 22:12:00 -0000 User-Agent: KMail/1.9.9 Cc: Daniel Jacobowitz References: <200806152205.49241.pedro@codesourcery.com> <20080625201946.GH25575@caradoc.them.org> <200806252217.25796.pedro@codesourcery.com> In-Reply-To: <200806252217.25796.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806252223.18858.pedro@codesourcery.com> 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: 2008-06/txt/msg00457.txt.bz2 A Wednesday 25 June 2008 22:17:25, Pedro Alves wrote: > A Wednesday 25 June 2008 21:19:46, Daniel Jacobowitz wrote: > > > @@ -1489,6 +1580,9 @@ linux_nat_resume (ptid_t ptid, int step, > > > /* Mark this LWP as resumed. */ > > > lp->resumed = 1; > > > > > > + /* Remove the SIGINT mark. Used in non-stop mode. */ > > > + lp->sigint = 0; > > > + > > > > Confused. Why does resuming the thread affect whether we have sent it > > a SIGINT, but not received it back yet? > > Hmm, I was under the impression that it was possible to push more > than one SIGINT into a thread's signal queue, but I just tried it, and > it doesn't seem like it is. This check was meant to prevent that > happening. I'm confused. It does seem I can put more than one SIGINT in the queue sometimes afterall. (I just changed the code to do two kill's in a row instead of one). If so, the check is needed to prevent the race where the thread hasn't reported the stop due to the SIGINT yet, so is_stopped is still false, and the user is doing "interrupt" on it (/me imagines user clicking a bunch of times on the IDE button). The clearing on resume was just a safe place to always clear it. -- Pedro Alves