From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22013 invoked by alias); 12 Aug 2005 20:57:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21984 invoked by uid 22791); 12 Aug 2005 20:57:17 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 12 Aug 2005 20:57:16 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1E3gaY-00089x-CO; Fri, 12 Aug 2005 16:57:14 -0400 Date: Fri, 12 Aug 2005 21:01:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20050812205714.GB30801@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com References: <20050809181311.GB3012@white> <20050809223421.GB3557@white> <20050810004128.GA4264@nevyn.them.org> <20050810004826.GD3557@white> <2040BEEA-4200-4118-91EB-D093ED4D37A1@apple.com> <20050812012810.GA10011@white> <20050812114929.GB10917@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-08/txt/msg00144.txt.bz2 On Fri, Aug 12, 2005 at 08:13:17PM +0300, Eli Zaretskii wrote: > I dislike using observers because, in a C program, that looks > suspiciously like the coder doesn't know what the program is doing. C > is not a polymorphic language, so in a C program events happen and > data of certain type arrives via a 100% predictable and deterministic > path. If you know where the event happens which you want to hook, > simply arrange for your function to be called directly by whatever > generates or receives that event. The main reason that I have advocated observers in GDB, in the past, is for the cases where "we don't know what the program is doing" - things specific to a target or group of targets or an optional module, so that we don't have #ifdefs all over the code for targets which ought to be self-contained. Also, even in C there can be multiple places logically generating an "event" - for a perfect example, look at observer_notify_inferior_created. I do understand your objections, though I'm not sure what to do about them. Personally, I'd love to solve the problem by switching to C++. In any case, I don't know that the observers implementation, per se, is a good fit for this particular usage anyway. MI is not an optional component, nor would most of the events in question be optional components; the data flow is simple, just as you described above. We can just call MI at the right points. Or add a small level of abstraction, and call all registered interfaces (TUI, CLI, MI) and see if any of them need to generate notifications. That doesn't change the basic idea of notifying MI at interesting events, which I think is a nice one. -- Daniel Jacobowitz CodeSourcery, LLC