This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: interpreters


Elena,

On Monday, September 30, 2002, at 05:35  PM, Elena Zannoni wrote:


Jim,

I am looking at the branch that Keith created for the interpreters
machinery, and trying to help with a breakdown to merge it back.

I have a question about do_one_event and this comment in interps.c:


2) The event loop insertion is probably wrong. I just inserted a
do_one_event alongside gdb's do_one_event. This probably will lead
to one or the other event loop getting starved. It would be better
to provide conversion functions for the gdb file handlers, and when
an interpreter starts up, it grabs all the gdb created file handlers
and inserts them into its select. This is more complicated, however,
and I have run out of time for now.


Such do_one_event_proc function just returns 1 in the cli case and
doesn't exist in the mi case. I don't see how this fits in with
start_event_loop.

Do these changes depend on something else that is not in the branch yet?

This code is still just a sketch of what you would have to do for a real interpreter - i.e. Tcl, Python, etc, and probably wrong at that.

The problem this code was trying to address was how to deal with the case where you were running with an interpreter that had its own event sources. So, for instance, if you wanted to write a Tcl interpreter for gdb, when you came around to the do_one_event part of the loop, you would need to drain the Tcl event sources, as well as read from gdb's stdin events & events from the inferior. The cheesy way to do this is to make do_one_event be "do_one_event_from_each_interpreter". This was the way that we did the "embedding Tk in a Motif or Xt event loop" cases. It sort of works.

As the comment suggests, however, the better way to do this is to require each interpreter to provide a "internalize gdb event source" which would take a source in some useful format (something select-able is probably best) and an event callback. Then the interpreter could use its own main loop - which is probably going to work better, and still fetch data from & call the handlers for, gdb's events. But I ran out of time before I got a chance to work out any of these ideas more fully.

Jim
--
Jim Ingham jingham@apple.com
Developer Tools - gdb
Apple Computer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]