From: Fernando Nasser <fnasser@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>,
Don Howard <dhoward@redhat.com>,
Fernando Nasser <fnasser@cygnus.com>,
Michael Snyder <msnyder@cygnus.com>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost]
Date: Wed, 19 Sep 2001 14:44:00 -0000 [thread overview]
Message-ID: <3BA9109A.73AC504B@redhat.com> (raw)
In-Reply-To: <1010919212147.ZM15180@ocotillo.lan>
Kevin Buettner wrote:
>
> This doesn't sound too bad; if the patches look reasonable, I may change
> my mind...
>
I am sconfident it can be small. I don't know if this is what Don's
next patch
will do, but if it is we will know for sure.
> HOWEVER, I'm against reference counts in general because it can be
> very hard to get the counter increments / decrements put in the right
> places. If you screw it up, you either get memory leaks or memory
> corruption or both. If we're contemplating the use of reference
> counts for other areas of GDB, I think we ought to rethink the problem
> and use some other garbage collection technique instead.
>
Lets not get carried over :-) I am not proposing it as a GDB
programming
style in general. I just suggested it as an algorithm to solve a
specific
problem with low overhead. Don't worry.
The ref counts can get really messy if everyone has to deal with them.
But, if properly encapsulated, most programers will not even know that
they are
dealing with ref counts and the chances of leaks/corruption is very slow
(whoever programmed the object had worked 26 hours in a row or
something).
Take a look at the "Proxy" pattern on the "Design Patterns" book (and
blame
Andrew Cagney for reminding me of this book a few months ago ;-) ).
Regards,
Fernando
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
next prev parent reply other threads:[~2001-09-19 14:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-17 9:34 Don Howard
2001-09-17 15:39 ` Michael Snyder
2001-09-18 6:56 ` Fernando Nasser
2001-09-18 7:56 ` Andrew Cagney
2001-09-18 8:09 ` Fernando Nasser
2001-09-18 10:34 ` Michael Snyder
2001-09-18 17:47 ` Andrew Cagney
2001-09-18 18:03 ` Michael Snyder
2001-09-19 7:20 ` Fernando Nasser
2001-09-19 8:17 ` Andrew Cagney
2001-09-19 9:22 ` Fernando Nasser
2001-09-19 11:44 ` PRMS not TODO: " Andrew Cagney
2001-09-19 9:33 ` Don Howard
2001-09-19 12:08 ` Kevin Buettner
2001-09-19 12:18 ` Michael Snyder
2001-09-19 13:09 ` Kevin Buettner
[not found] ` <3BA905AD.5F8F1A68@redhat.com>
2001-09-19 14:22 ` Kevin Buettner
2001-09-19 14:44 ` Fernando Nasser [this message]
2001-09-20 15:24 ` Don Howard
2001-09-20 18:05 ` Andrew Cagney
[not found] <Pine.LNX.4.33.0109211638230.1755-100000@theotherone>
2001-09-24 17:10 ` Kevin Buettner
2001-09-24 17:33 ` Kevin Buettner
2001-09-24 18:52 ` Andrew Cagney
2001-09-26 13:07 ` Fernando Nasser
2001-09-26 14:20 ` Kevin Buettner
2001-09-26 14:57 ` Fernando Nasser
2001-09-26 15:09 ` Andrew Cagney
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=3BA9109A.73AC504B@redhat.com \
--to=fnasser@redhat.com \
--cc=ac131313@cygnus.com \
--cc=dhoward@redhat.com \
--cc=fnasser@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@cygnus.com \
--cc=msnyder@cygnus.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