Re: plan for python inferiors, threads, and events

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

El vie, 12-12-2008 a las 12:11 -0700, Tom Tromey escribiÃ:
> I've been looking at writing a Python API to the inferior and threads.
> It got complicated enough that I thought I would post a note
> describing my plan before going off and implementing it.  I'd
> appreciate your thoughts on the subject.

I'm ressurecting this thread because I noticed that we have to get this
sorted out before I can post the patch exposing inferior frames to
Python (which is a pity, the patch is almost ready).

> * It ought to keep working once gdb moves to multi-process.  E.g., the
>   current "gdb.threads" stuff is not super in this regard (IMO).

I agree, but I believe that single-process debugging sessions will be
more common than multi-process ones. Because of this, IMHO we should
provide a way for users to write scripts and python code snippets
without having to worry about multi-process issues. Cases in point are
the caller_is and in_scope convenience functions.

> class gdb.Inferior
> 
>   Represents a single inferior.
> 
>   Some attributes:
>
>   * pid.  The inferior pid.  It isn't clear how useful this is to
>     expose, given remote debugging and whatnot.

Two additional attributes that could be interesting are: 'is_remote' and
'is_live'. That way, a python script can know if it can use the pid
attribute or not.

>   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.

I think these would be useful.

> 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?

There are two ways of importing a package:

- import blah
- from blah import *

In the latter case, classes and objects can be used without specifying
the package name. So if InferiorThread was named just Thread, and a
script imports both the gdb and the threading packages, they would
clash. I don't know how Python deals with this name conflict.

So I prefer InferiorThread.

>   Some attributes:
<snip>
>   * 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.

For things that can change with time, I prefer to use methods rather
than attributes. It feels more natural to have a method which can return
different things at each call, than an attribute which will magically
change each time it is accessed.

>   * 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
>     clear.

Perhaps we can have this event in both Inferior and InferiorThread.
Then, in all-stop mode, the event in the Inferior says why it stopped,
and the events in each thread say that they were stopped by GDB (or
alternatively, that they stopped because the whole Inferior stopped).

I don't know if this is actually doable, since Pedro says:

> One could say that it would be nice to be able to query a thread
> about why is it that it is stopped, but that isn't currently possible.
> GDB
> discards part of the interesting info while/after handling an event.

>   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?

I agree with Paul in that both Inferior and InferiorThread should have
such method.

>   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:
> 
>       thread.stop_event.connect(callback)

Agreed.

>   I think we can reuse this class in other places, eventually.

To notify about signals from the inferior, maybe? Or would this just be
a special case of the stop_event, with a stop reason mentioning the
signal?
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center