From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7402 invoked by alias); 6 Sep 2007 06:46:38 -0000 Received: (qmail 7391 invoked by uid 22791); 6 Sep 2007 06:46:36 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 06:46:32 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1ITB8G-0008Gg-Dv for gdb@sources.redhat.com; Thu, 06 Sep 2007 10:46:28 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ITB89-0008GN-I9; Thu, 06 Sep 2007 10:46:21 +0400 From: Vladimir Prus To: Eli Zaretskii Subject: Re: MI: "^running" issues Date: Thu, 06 Sep 2007 07:20:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb@sources.redhat.com References: <200709041653.22357.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709061046.21723.ghost@cs.msu.su> 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: 2007-09/txt/msg00043.txt.bz2 On Thursday 06 September 2007 07:19:11 Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Wed, 05 Sep 2007 22:41:38 +0400 > > > > > Asynchronous execution means that some GDB commands can be run while > > > GDB waits for the target to stop. It is good for users because you > > > can do something useful while you wait for the target to stop. > > > > Unfortunately, I never saw more concrete details. > > That's because introduction of asynchronous execution into GDB was > never finished. > > > What commands are actually meaningful to emit while target are > > running > > Anything that does not need the target itself, or modifies its state. > For example, "help". I hope you'll agree that "help" is not important enough to warrant extensive gdb work, so let's drop this example immediately. > A less trivial example is "info break" (to see > what breakpoints were already hit during execution up to now, in case > your "commands" for the breakpoints continue the target). Technically speaking, you don't need async for that -- you can interrupt the target, provide output, and then go on. Making this async will maybe cut some fraction of section from the run time, why do we care? > Note that I'm not actually saying these commands will work > asynchronously in the current GDB, as the implementation of async > execution was never finished, AFAIK. > > > and are those commands of big enough value to user to warrant > > extensive coding? > > "Big enough" is in the eyes of the beholder. In principle, every > command in GDB that could take a long time could run in the > background, and GDB could be free to accept other commands in the > meantime. Except for commands that run target, I know of only various get-symbol-list commands that can take large time, and target memory access (load, disass, raw memory access). Are there some other commands? While those indeed can be parallelized to some degree, I don't particularly see the end-user use-cases where that's useful. > So you are in effect questioning the value of > multithreading. Multithreading is not a silver bullet. It should be used when appropriate. Are you sure gdb code is thread-safe in any degree? > As another data point, the people who wrote the infrastructure for the > async execution were two long-time and experienced GDB users and > developers, and they obviously thought it was worth coding. This is argument by authority, I don't accept it. > > Can interested parties document those commands at GDB Wiki, or even > > in email? > > The list depends on what we decide to code, so I don't think anyone > can publish it now. I think at least some design should be present before coding, so it would be reasonable that anybody who submits some async patches be ready to explain the final goal -- what commands will be async, will it be just async, or multithreaded, and what will be essential benefits for CLI user and for frontends. The way it stands now is more like "let's develop async mode, and then see what commands we can run in async mode, and then see what benefit that will have". - Volodya