From: "Eli Zaretskii" <eliz@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Modified Watchthreads Patch
Date: Sat, 11 Dec 2004 11:32:00 -0000 [thread overview]
Message-ID: <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> (raw)
In-Reply-To: <20041210233700.GA24439@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 10 Dec 2004 18:37:00 -0500)
> Date: Fri, 10 Dec 2004 18:37:00 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 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.
next prev parent reply other threads:[~2004-12-11 11:19 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-10 4:24 Jeff Johnston
2004-12-10 13:31 ` Eli Zaretskii
2004-12-10 14:21 ` Daniel Jacobowitz
2004-12-10 18:01 ` Jeff Johnston
2004-12-24 11:05 ` Michael Snyder
2005-01-07 0:23 ` jjohnstn
2004-12-10 23:01 ` Eli Zaretskii
2004-12-10 23:31 ` Daniel Jacobowitz
2004-12-10 19:10 ` Jeff Johnston
2004-12-10 22:51 ` Eli Zaretskii
2004-12-23 22:32 ` Michael Snyder
2004-12-24 14:46 ` Eli Zaretskii
2004-12-10 20:03 ` Daniel Jacobowitz
2004-12-10 20:30 ` Jeff Johnston
2004-12-10 20:47 ` Daniel Jacobowitz
2004-12-10 22:18 ` Jeff Johnston
2004-12-10 23:57 ` Jeff Johnston
2004-12-11 0:31 ` Daniel Jacobowitz
2004-12-11 1:28 ` Jeff Johnston
2004-12-11 14:34 ` Eli Zaretskii
2004-12-11 16:56 ` Daniel Jacobowitz
2004-12-11 18:01 ` Eli Zaretskii
2004-12-11 18:06 ` Daniel Jacobowitz
2004-12-11 19:08 ` Eli Zaretskii
2004-12-11 19:30 ` Daniel Jacobowitz
2004-12-12 5:22 ` Eli Zaretskii
2004-12-11 21:54 ` Mark Kettenis
2004-12-11 14:53 ` Mark Kettenis
2004-12-11 16:52 ` Eli Zaretskii
2004-12-11 2:04 ` Daniel Jacobowitz
2004-12-11 16:11 ` Mark Kettenis
2004-12-10 23:06 ` Eli Zaretskii
2004-12-10 23:10 ` Daniel Jacobowitz
2004-12-10 23:37 ` Eli Zaretskii
2004-12-10 23:52 ` Daniel Jacobowitz
2004-12-11 11:32 ` Eli Zaretskii [this message]
2004-12-11 14:49 ` Mark Kettenis
2004-12-11 16:48 ` Daniel Jacobowitz
2004-12-11 17:33 ` Eli Zaretskii
2004-12-11 17:53 ` Daniel Jacobowitz
2004-12-11 18:07 ` Eli Zaretskii
2004-12-11 18:50 ` Daniel Jacobowitz
2004-12-11 19:06 ` Mark Kettenis
2004-12-11 19:07 ` Daniel Jacobowitz
2004-12-11 16:49 ` Eli Zaretskii
2004-12-11 16:37 ` Daniel Jacobowitz
2004-12-11 17:30 ` Eli Zaretskii
2004-12-11 17:38 ` Daniel Jacobowitz
2004-12-11 18:02 ` Eli Zaretskii
2004-12-11 18:10 ` Daniel Jacobowitz
2005-01-13 19:22 ` Jeff Johnston
2005-02-11 1:57 ` Daniel Jacobowitz
2005-02-11 18:18 ` Eli Zaretskii
2005-02-11 18:31 ` Daniel Jacobowitz
2005-02-12 21:50 ` Eli Zaretskii
2004-12-11 19:35 Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il' \
--to=eliz@gnu.org \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jjohnstn@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox