This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: non-blocking reads/writes and event loops
- To: Todd Whitesel <toddpw at windriver dot com>
- Subject: Re: non-blocking reads/writes and event loops
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 15 Jun 2000 11:35:46 +1000
- CC: Jim Ingham <jingham at apple dot com>, gdb at sourceware dot cygnus dot com, "Insight (GDB GUI)" <insight at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
- References: <200006141746.KAA29364@alabama.wrs.com>
Todd Whitesel wrote:
>
> > However, threads may need to be used in the case where you only have a
> > blocking API to control the inferior, but in that case all you are doing is
> > using threads to fix this local deficiency, not pushing it into the gdb
> > architecture. I think this is managable.
>
> Agreed. If the API designers are dumb enough to trust threads absolutely,
> and don't give us an option, then well, that's life.
For what it is worth, here is the ``It is hard'' reason number two:
In addition to the expression evaluator, every physical target (that is
the bit that knows how to read/write memory and registers) needs to be
inverted. The basic programming model used when developing them
requiring a full rewrite.
At present a memory/register IO looks like (vaguely):
event-loop
tty event: (gdb) print ...
-> expression-evaluator
-> target->read()
-> os/remote->read()
<- data
<- data
<- evaluate
print
at the target level, since we are inverting things, it would need to be
broken down into several transactions:
event-loop
tty-event: (gdb) print ...
-> expression-evaluator
-> target->request_read ()
-> os/remote->request_read ()
event-loop
os/remote-event: some data ready
-> os/remote->supply_some_of_data()
event-loop
os/remote-event: some data ready
-> os/remote->supply_rest_of_data() (all data ready)
-> target->supply_data()
->expression_evaluator->supply_data()
event-loop
->expression-evaluator->display()
(please don't nit-pick on the detail :-). The point being that you are
introducing a fundamentally different programming model into _all_
levels of GDB. You are no longer using procedures but instead passing
around messages and writing state machines or similar. All of which are
not mechanical.
Just making certain that your eyes are open :-)
Andrew