From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22999 invoked by alias); 14 Jul 2008 15:56:33 -0000 Received: (qmail 22990 invoked by uid 22791); 14 Jul 2008 15:56:33 -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 15:56:11 +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 m6EFtfVU010438; Mon, 14 Jul 2008 08:55:41 -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 08:55:41 -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 08:55:41 -0700 Message-ID: <487B76FC.1090403@windriver.com> Date: Mon, 14 Jul 2008 15:56: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: <6D19CA8D71C89C43A057926FE0D4ADAA04291230@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA04291230@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/msg00155.txt.bz2 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. This is certainly inconvenient, but given the fact that it only applies to CLI commands, it should not have a performance impact. Cheers, Pawel