From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16958 invoked by alias); 24 May 2002 22:26:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16936 invoked from network); 24 May 2002 22:26:52 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 24 May 2002 22:26:52 -0000 Received: from makita.cygnus.com (makita.sfbay.redhat.com [192.168.30.83]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA15896; Fri, 24 May 2002 15:26:51 -0700 (PDT) Received: from localhost (keiths@localhost) by makita.cygnus.com (8.8.8+Sun/8.6.4) with ESMTP id PAA19763; Fri, 24 May 2002 15:26:50 -0700 (PDT) X-Authentication-Warning: makita.cygnus.com: keiths owned process doing -bs Date: Fri, 24 May 2002 15:26:00 -0000 From: Keith Seitz X-X-Sender: To: Andrew Cagney cc: Subject: Re: [MI] Synchronous event notification In-Reply-To: <3CEEA58A.8090209@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-05/txt/msg00274.txt.bz2 On Fri, 24 May 2002, Andrew Cagney wrote: > So: > > ^done,result=...,events=... > > So that, for a ``synchronous'' command the events just get bundled with > the result. Sounds ok, definitly has a certain elegance - here is the > result, here are all the sideeffects. It has that as an advantage, but it also has one minor disadvantage: we'd be processing events for synchronous targets and async targets differently. > One question, what about a more asynchronous operation? A running > target starts loading shared libraries, inserting breakpoints, running > scripts, et.al. There the synchronous nature is gone. I guess: > > - notify of all the events when the target next ``stops'' > > - notify the events on-the-fly (possibly incuring an overhead?) YES! This is exactly what I would prefer to see done. _All_ events come out on a channel. Then it won't matter if the target is sync or async: events are async in nature: (gdb) -interpreter-exec console "break foo" &Breakpoint 1, ... *breakpoint-create,bkpt=... (gdb) -break-insert main *breakpoint-create,bkpt=... (gdb) UIs prefer to respond to events when something happens. In the later case above, we've asked gdb to install a breakpoint at main, but the UI won't actually do anything (like update breakpoint markers or breakpoint windows) UNTILL it gets the event from gdb. So, if we need to vote, I vote that we output aync events all the time. (Of course, this would mean we really need to get target output nailed for the natives, but that's another battle.) Keith