This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: interpreters
- From: Jim Ingham <jingham at apple dot com>
- To: Elena Zannoni <ezannoni at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 1 Oct 2002 13:15:46 -0700
- Subject: 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