This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: MI output during program execution


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 <bob@brasko.net>
> > 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 <bob@brasko.net>
> > > > Cc: Eli Zaretskii <eliz@gnu.org>, 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]