This is the mail archive of the
mailing list for the Archer project.
Re: plan for python inferiors, threads, and events
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Fri, 12 Dec 2008 11:52:05 -0800
- Subject: Re: plan for python inferiors, threads, and events
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;t=1229111529; bh=u6uQXgbJdaVWGMi8gj5JBSlg9Bo=;h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; b=KJ3oOWR1o2mqzP18lRXCvtL46sHv+hkYGqlig+NtB+qPWo3s1vaNe5KKILiEyuH1nX1R8BUaXZkFi6c1kYvk/g==
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;h=mime-version:in-reply-to:references:date:message-id:subject:from:to:cc:content-type:content-transfer-encoding;b=GOXpYf8fpFTpFX+qwPs1GholAPeXnIGVJ1VPiqyUWt09gr1SuCVHDkDSKX0Qwf3R0kQM2jjqGN9t7qnhwEK5CA==
- References: <email@example.com>
On Fri, Dec 12, 2008 at 11:11 AM, Tom Tromey <firstname.lastname@example.org> wrote:
> class gdb.Inferior
> * pid. The inferior pid. It isn't clear how useful this is to
> expose, given remote debugging and whatnot.
Python code may wish to do some logging; pid will likely be very
useful for that.
> * threads. A tuple holding all the currently existing threads of
> this inferior. A "live" inferior always has at least one thread.
> When the threads change internally, the implementation will update
> this tuple.
> Note that gdb internally keeps a global list of all threads. So,
> segregating threads according to the inferior is an abstraction we
> would supply under the hood.
> See below for thread details.
> Maybe we need some events here? "thread_started"? Events to notify
> changes in the overall inferior state?
> Some methods:
> * run. Start the inferior.
> A few things I am not as sure about:
> * Add method to fetch the command-line arguments? There are other
> per-inferior attributes like this, too: working directory,
> environment. Maybe some gdb-side settings, like target-charset.
> * Should we move gdb.objfiles here? Abstractly, I would say yes.
> The intent of the multiprocess branch here is not clear to me,
AFAIU, there are 2 distinct scenarios for multiprocess:
A: several instances of the same executable, and
B: several unrelated executables.
For B, .objfiles still clearly belongs to Inferior.
For A, IMHO it still belongs to Inferior -- even instances of
the same executable may have different .objfiles (e.g. due to
different libraries being loaded dynamically, or even at startup
due to different LD_LIBRARY_PATH).
> * I'd like to have a constructor so that user code can easily set up
> a new Inferior, with some arguments, and start it. Perhaps for
> the time being we could do this by restricting gdb to a single
> Inferior instance... ?
> class gdb.InferiorThread
> This represents a single inferior thread.
> I didn't name this "Thread" since there is already a commonly-used
> Python class of that name... or maybe we should use Thread and just
> let packages work their magic?
> Some attributes:
> * Maybe ptid? The thread id.
Yes, for the same reason as pid.
> * state. The state of the thread -- running, stopped, etc. This
> means taking the various is_* functions from gdb and turning them
> into a set of state values.
> * stop_event. An event which is fired when a thread stops. The
> stop reason (struct bpstats) would be passed as an argument. See
> below for info about events.
> It isn't totally clear that this is the correct abstraction. In
> some modes (non-stop), I think it is. In all-stop, it seems less
> * continue_event. Fired with no arguments when the thread starts
> running again.
> * exited_event. Fired when the thread exits.
> Right now, no methods. It seems like we'd want a way to let user
> code request a stop ("interrupt the inferior now")... should this be
> on Thread or on Inferior?
Or on both: the script may wish to stop one thread, or the entire
> class gdb.Event
> An event is just a container. User code puts functions into the
> container. Firing an event just means walking through all the
> functions, and calling them with whatever arguments the event has.
> * connect (function). Add function.
> * disconnect (function). Remove function.
> * emit (args). Fire the event.
> The names here are inspired by GObject. However, I dislike using
> strings for event names; why not just use Python attributes instead?
> So rather than the Gtk-ish:
> thread.connect("stop", callback)
> We will have:
> I think we can reuse this class in other places, eventually.