Re: plan for python inferiors, threads, and events

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Fri, Dec 12, 2008 at 11:11 AM, Tom Tromey <tromey@redhat.com> 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.

Me too.

>    The intent of the multiprocess branch here is not clear to me,
>    though.

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

> 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.
>
>  Methods:
>
>  * 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:
>
>      thread.stop_event.connect(callback)
>
>  I think we can reuse this class in other places, eventually.
>
> Tom
>



-- 
Paul Pluzhnikov