This is the mail archive of the
mailing list for the Archer project.
Re: [python][commit] Add interface for inferior manipulation.
- From: Tom Tromey <tromey at redhat dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: archer ml <archer at sourceware dot org>
- Date: Tue, 21 Apr 2009 19:15:28 -0600
- Subject: Re: [python][commit] Add interface for inferior manipulation.
- References: <firstname.lastname@example.org>
- Reply-to: Tom Tromey <tromey at redhat dot com>
I'm sorry for not getting back to you on this sooner.
And, actually, I still really haven't read the patch, I just wanted to
respond to one thing.
Thiago> I coded it this way because it seemed important/useful to always have
Thiago> only one Python object for each GDB inferior or thread. Perhaps I'll
Thiago> revisit this though, and create Python objects on demand (thus
Thiago> permitting more than one Python instance for each inferior or thread).
I think it is important to have a single Python object per GDB
object. I don't like this situation with Type, where we can make
multiple new ones -- it is confusing to use objects that behave this
way. I would like us to not add to this problem :-)
Managing the lifetimes of Python objects like this can be a pain.
But, for Inferior and InferiorThread, I think it would be ok to add a
field to the gdb core structures -- it may be more palatable to do
something like the objfile data thing, or otherwise just a plain
python object. I think this is ok here because it is very unlikely
that these structures will ever be memory abusers; so, growing them by
a field just doesn't matter.