Re: plan for python inferiors, threads, and events

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

Thiago> Take, for instance, the gdb.{read,write,search}_memory functions. They
Thiago> should be methods in the gdb.Inferior class. But if we keep them as
Thiago> functions in the gdb module, and have them mean "do these actions in the
Thiago> current and/or selected inferior", we save a lot of people from having
Thiago> to type gdb.selected_inferior (). Ithink this would avoid some of the
Thiago> Java silliness of having to call big strings of methods to get what you
Thiago> want.

I tend to prefer explicit use of objects, rather than implicit use of
globals, because it is easier to understand.  I don't mind the extra
text very much.

I do agree with your point that single-inferior is going to be the
common case.

I've been trying to think of drawbacks of the "use a global" approach.

First, user code will still have to fetch the current inferior (or
thread) to register an event handler.  This is an odd asymmetry,
though not very important.

But thinking about events got me wondering... suppose we emit an event
for some inferior.  Should we make that the current inferior for the
duration of the event?  If so, should we reset the current inferior
after event emission has completed?  That is a bit of a trick
question: if some event handler switches inferiors, it will mess up
the expected global state for other handlers; but if the inferior is
always reset, then there is no simple way to have event emission
affect the user's view.  Also, if we do change the current inferior,
suppose we want to also see the previous (user's) current inferior --
we'd need a second global.

Thiago> A similar argument can be made about threads (so we would keep
Thiago> gdb.frames and gdb.{current,selected}_frame) to save one call to
Thiago> gdb.{current,selected}_thread.

We could redefine these as convenience functions that access the
current inferior, if we want to keep them.

Thiago> I think gdb.selected_frame can be kept
Thiago> regardless, since there's only one selected frame even in multi-threaded
Thiago> apps, IIRC.

Yeah.  Generally, I think only code that is user-facing ought to be
messing with the "selected" anything.

Tom