From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3495 invoked by alias); 14 Jul 2008 16:04:03 -0000 Received: (qmail 2652 invoked by uid 22791); 14 Jul 2008 16:03:36 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 16:03:15 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m6EG34QB000491; Mon, 14 Jul 2008 11:03:10 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 11:03:09 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: MI threads behaviour Date: Mon, 14 Jul 2008 16:04:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0429124A@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <487B76FC.1090403@windriver.com> From: "Marc Khouzam" To: "Pawel Piech" Cc: "Daniel Jacobowitz" , "Vladimir Prus" , 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/msg00158.txt.bz2 > -----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 >=20 >=20 > Marc Khouzam wrote: > >> The =3Dthread-selected notification, in this case, should be=20 > 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=20 > this case the > >> frontend need to use this information to figure if=20 > -thread-select should be > >> sent. > >>=20=20=20=20=20 > > > > Here, I believe there is a race condition. In the example=20 > you give above with > > two windows, one window could send a CLI command changing=20 > the thread, but > > the second window may send an MI command, before receiving the > > =3Dthread-selected notification and will act on the wrong thread. > > I don't see how we could fix this. > > Or maybe I misunderstood your explanation? > >=20=20=20 > Hi Marc, > I seem to remember that we talked about the fact that there is a race=20 > condition and decided that it is unavoidable. Our proposed=20 > workaround=20 > was to force the client to wait for the result of each CLI command=20 > before issuing another CLI or MI command.=20=20 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 > This is certainly=20 > inconvenient, but given the fact that it only applies to CLI=20 > commands,=20 > it should not have a performance impact. >=20 > Cheers, > Pawel >=20