From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11139 invoked by alias); 14 Jul 2008 20:27:16 -0000 Received: (qmail 11130 invoked by uid 22791); 14 Jul 2008 20:27:15 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 20:26:51 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m6EGmi8n029476; Mon, 14 Jul 2008 09:53:09 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 09:52:38 -0700 Received: from [147.11.233.129] ([147.11.233.129]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 09:52:38 -0700 Message-ID: <487B8455.6030607@windriver.com> Date: Mon, 14 Jul 2008 20:27:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Marc Khouzam CC: Daniel Jacobowitz , Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI threads behaviour References: <6D19CA8D71C89C43A057926FE0D4ADAA0429124A@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA0429124A@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00173.txt.bz2 Marc Khouzam wrote: > >> -----Original Message----- >> From: Pawel Piech [mailto:pawel.piech@windriver.com] >> Sent: Monday, July 14, 2008 11:56 AM >> To: Marc Khouzam >> Cc: Daniel Jacobowitz; Vladimir Prus; gdb@sources.redhat.com >> Subject: Re: MI threads behaviour >> >> >> Marc Khouzam wrote: >> >>>> The =thread-selected notification, in this case, should be >>>> >> interpreted to >> >>>> mean: >>>> (1) User's request that the selected thread be changed, and >>>> (2) Notification that GDB current thread has changed >>>> The (2) trait does not matter if --thread is used, but in >>>> >> this case the >> >>>> frontend need to use this information to figure if >>>> >> -thread-select should be >> >>>> sent. >>>> >>>> >>> Here, I believe there is a race condition. In the example >>> >> you give above with >> >>> two windows, one window could send a CLI command changing >>> >> the thread, but >> >>> the second window may send an MI command, before receiving the >>> =thread-selected notification and will act on the wrong thread. >>> I don't see how we could fix this. >>> Or maybe I misunderstood your explanation? >>> >>> >> Hi Marc, >> I seem to remember that we talked about the fact that there is a race >> condition and decided that it is unavoidable. Our proposed >> workaround >> was to force the client to wait for the result of each CLI command >> before issuing another CLI or MI command. >> > > With the example of two windows, can we block an MI command on window 2 > waiting for the CLI command to finish on window 1? > I guess I didn't fully understand the example. > Either way, I'm sure this solution if fine. > > Thanks > > Yes, so the blocking will have to be controlled at a low level based on the command type being sent. What could prove to be more tricky is figuring out how to handle the possible flood of =thread-selected events for MI commands. Two simple options would be to either just ignore this event while processing MI commands, or two use the --thread option to avoid the event all together. Cheers, Pawel >> This is certainly >> inconvenient, but given the fact that it only applies to CLI >> commands, >> it should not have a performance impact. >> >> Cheers, >> Pawel >> >>