This is the mail archive of the
mailing list for the GDB project.
Re: [Python - doc] gdb.post_event description
Kevin Pouget <firstname.lastname@example.org> writes:
> On Fri, Oct 14, 2011 at 9:48 PM, Tom Tromey <email@example.com> wrote:
>>>>>>> "Kevin" == Kevin Pouget <firstname.lastname@example.org> writes:
>> Kevin> according to my experimentations, gdb_do_one_event, which (indirectly)
>> Kevin> triggers the processing of Python events posted with gdb.post_event,
>> Kevin> is executed right after the prompt has been displayed (and new
>> Kevin> charactered fed in), and nowhere else (as far as I could investigate).
>> Kevin> Does it look right to you?
>> Yeah, but I would not want to document this too precisely; it is good, I
>> think, to have some leeway so we can run the event queue at other times
>> if we find the need in the future.
> but I think that the notion of "event" is quite vague here, for
> instance we've got Python events, which are totally unrelated to
> "post_event" (as far as I understood); and internally there are
> inferior events.
> (Actually, with that knowledge, I expected 'post_event' events to be
> processed more often).
> So I think it's important to state when the callback will be
> triggered, give the prompt as an example, and mentioned that more
> event processing points might be added in the next releases
> What do you think about it?
Sorry I did not see this until now. The problem is that events are
processed in GDB (I believe) at different times, in different parts of
the code, and more importantly are subject to change.
So if we document "blah event will be processed after foo operation",
then there is an expectation is that it will also be so. We have
exposed an internal mechanic of GDB and cast it in an API promise. We
cannot live-up to that expectation. Nor should we, imo, imply any
guarantee when the event will be processed other than it will.