From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7271 invoked by alias); 4 Jun 2008 04:57:28 -0000 Received: (qmail 7259 invoked by uid 22791); 4 Jun 2008 04:57:26 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jun 2008 04:57:07 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K3l3T-00080G-04 for gdb@sources.redhat.com; Wed, 04 Jun 2008 04:56:59 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jun 2008 04:56:58 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jun 2008 04:56:58 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: RE: non-stop and current thread exiting Date: Wed, 04 Jun 2008 04:57:00 -0000 Message-ID: References: <200806032253.39575.pedro@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04E1BD47@ecamlmw720.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 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-06/txt/msg00016.txt.bz2 Marc Khouzam wrote: > Hi, > > so we all agree that a) is no good. > > b) and c) are good. > The advantage of b), as you point out, is that the user > can see which thread was previously selected. However, > since GDB will no longer be changing threads automatically, > a frontend will already know which thread was previously > selected. > > So, my first impression is that c) is actually better > since it keeps 'info thread' looking the same. Having b) report > a thread as (exited) will require the frontend to add extra > intelligence to parse that. > > This may not be true from a user's point-of-view > where she/he may not remember the previously selected thread. > But I haven't figured out if the user would really care. What I was thinking if that if you select a thread, and continue it, and the thread exits, it would be more user-friendly to gray this thread, add "(exited)" and then retire it next time we stop. The other alternative is either message box "thread is exited", which is obtrusive, or "passive popup", or message in status bar, which, on the contrary, can be easily ignored. You are right that some frontend changes will be required -- but they are required anyway to show the "running" state of the thread, so seems the extra change to show "exited" state does not add much complexity. > In the case of b) or c) one point that is important for the > a frontend is how GDB will react to prohibited commands > when no thread is selected? Will a prohibited command > cause an ^error or maybe an empty ^done, or something else? With (b), you always have some thread selected. When it is actually exited thread, I'd say ^error is the best way. If you send a command and get empty ^done, while you expect some data in the response, it's not very good, I think. - Volodya