From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25104 invoked by alias); 11 Dec 2004 11:19:50 -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 25078 invoked from network); 11 Dec 2004 11:19:41 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 11 Dec 2004 11:19:41 -0000 Received: from zaretski (IGLD-83-130-247-149.inter.net.il [83.130.247.149]) by legolas.inter.net.il (MOS 3.5.5-GR) with ESMTP id DHU14704 (AUTH halo1); Sat, 11 Dec 2004 13:18:56 +0200 (IST) Date: Sat, 11 Dec 2004 11:32:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <20041210233700.GA24439@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 10 Dec 2004 18:37:00 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch Reply-to: Eli Zaretskii References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <01c4df0c$Blat.v2.2.2$244dda20@zahav.net.il> <20041210230603.GA23419@nevyn.them.org> <01c4df10$Blat.v2.2.2$6f63d1a0@zahav.net.il> <20041210233700.GA24439@nevyn.them.org> X-SW-Source: 2004-12/txt/msg00293.txt.bz2 > Date: Fri, 10 Dec 2004 18:37:00 -0500 > From: Daniel Jacobowitz > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > I waited to review the revised version until you had a chance to > comment on the continued use of observers. I still object to the use of observers for a purpose such as this one. My objections are a bit philosophical, though. Basically, I think that observers are a last-resort mechanism for anything that is part of the GDB infrastructure. It's like hooks or callbacks--you don't normally expect a program internals to use callbacks that it provides for higher-level application code. Put another way, using a mechanism such as observers for internal code means we leave our internal structure not entirely defined. We design the internals, so we ought to know what needs to be done where and when. For example, this particular usage of an observer means that we don't really know in advance that watchpoint insertion needs to be done for each thread when it is being attached. Do we really want to say that we don't know what we are doing in our own program? Callbacks is something you generally provide for application code that is not part of the program. For example, if we ever get to the point of having libgdb that could be linked into other applications to create customized debuggers, observers will be an important mechanism to let libgdb users hook into internal GDB operations without hacking the code. In addition, proliferation of observers' use will sooner or later raise the issue of the order of the observer invocation, since we lack a machinery for invoking a series of observers in a controlled manner: we cannot control the order of their invocation and we cannot tell GDB to stop invoking any additional observers. The current machinery assumes that each observer is orthogonal to others in its side effects; what if this assumption doesn't hold? > Jeff asked you if a renamed observer was acceptable, and you said > that it was. That's because I didn't want to restart a dispute where I was already told that the party line was that it was okay to use observers for such puproses (or any puproses, really). > If there's been a miscommunication, if you still object to this use of > the observers, please, say so now. We can discuss alternatives. Well, the obvious alternative is to call the function that needs to insert the watchpoints for a thread that has been attached right where the thread attachment is dealt with.