From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5404 invoked by alias); 12 Aug 2005 20:31:06 -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 5389 invoked by uid 22791); 12 Aug 2005 20:31:01 -0000 Received: from eastrmmtao06.cox.net (HELO eastrmmtao06.cox.net) (68.230.240.33) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 12 Aug 2005 20:31:00 +0000 Received: from white ([68.9.64.121]) by eastrmmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050812203053.ERUO1393.eastrmmtao06.cox.net@white>; Fri, 12 Aug 2005 16:30:53 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1E3gB2-00033K-00; Fri, 12 Aug 2005 16:30:52 -0400 Date: Fri, 12 Aug 2005 20:45:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20050812203052.GA11539@white> 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.3.28i X-SW-Source: 2005-08/txt/msg00139.txt.bz2 On Fri, Aug 12, 2005 at 08:13:17PM +0300, Eli Zaretskii wrote: > > Date: Fri, 12 Aug 2005 07:49:29 -0400 > > From: Bob Rossi > > Cc: gdb-patches@sources.redhat.com > > > > On Fri, Aug 12, 2005 at 12:43:19PM +0300, Eli Zaretskii wrote: > > > > Date: Thu, 11 Aug 2005 21:28:10 -0400 > > > > From: Bob Rossi > > > > Cc: Eli Zaretskii , gdb-patches@sources.redhat.com > > > > > > > > Thanks for all the guidence so far. Even though you have not attempted > > > > the observer approach, how do you feel about it? Is this something that > > > > you think could be accomplished with the current FSF GDB? Nick, Daniel > > > > and Eli, do you like this approach? > > > > > > The record will show that I dislike using observers in core GDB > > > sources (i.e. in the sources released with official GDB > > > distributions). But my opinions on this are usually voted down. > > > > I would like to become more educated on the pros/cons of the two possible > > approaches in solving this problem. What do you not like about the > > observer approach that the hook approach solves better? > > I'm not sure what you mean by ``the hook approach''. From my point of > view, observers are simply one implementation of the hook approach. Yes, as I was thinking about this later, I realized that this was true. However, I was thinking the the "hook approach=>jim's implementation", was simply an implementation of the observer design pattern. The observer pattern can be defined as, Define a one-to-many relationship between objects so that when one object changes state, all its dependents are notified and updated automatically. Obviously, there is a 1-1 relationship between the FE and GDB, but I don't think that should be a big deal. > 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. OK, this seems reasonable. One thing to note is that the FE may be in C++ or Java, which would lend nicely to the Observer design pattern. CGDB is written in C, so this doesn't really matter to me. > In addition, using observers raises an issue with multiple observers > watching the same events and stepping on each other's feet. In other > words, the observer facility doesn't promise anything about the order > in which the observers are invoked, and doesn't give us control on the > order, so a potential arises for conflicts, if several observers futz > with the same data structures or try to produce opposite effects. Agreed. However, there is only a single observer in this case, right? Thanks for the info, Bob Rossi