From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16265 invoked by alias); 5 May 2008 19:44:29 -0000 Received: (qmail 16253 invoked by uid 22791); 5 May 2008 19:44:28 -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, 05 May 2008 19:44:03 +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 m45Ji1MY021431 for ; Mon, 5 May 2008 12:44:01 -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, 5 May 2008 12:44:00 -0700 Received: from [147.11.233.140] ([147.11.233.140]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 12:44:01 -0700 Message-ID: <481F6380.3010101@windriver.com> Date: Mon, 05 May 2008 19:44:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: Reporting non-stop support References: <200805042102.30612.vladimir@codesourcery.com> <481F356B.2050800@windriver.com> In-Reply-To: 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-05/txt/msg00045.txt.bz2 I don't think a "non-stop" mode needs to be enabled by a "check box". It's more of a property of a target rather than a feature that a user requests. Depending on what kind of target the user is connecting to, he will likely know beforehand whether it supports non-stop debugging, and if it does, he will naturally want it enabled. Cheers, Pawel Vladimir Prus wrote: > Pawel Piech wrote: > > >> I just think this shows how important it is that the client be able to >> use the same protocol to communicate in either mode, and be able to use >> the event data alone to determine what state actually changed on the target. >> > > Heh, I don't think so. Do you really think it's acceptable to have a "non-stop" > checkbox in UI that will not actually work, and find out that it does not work > only when your program stops for the first time -- stopping all threads? I think > this is not acceptable in any way -- regardless of how carefully and politely > gdb phrases "all threads stopped, your real time application is messed up" > information. > > - Volodya > > >