This is the mail archive of the
mailing list for the GDB project.
Re: non-blocking reads/writes and event loops
- To: Todd Whitesel <toddpw at windriver dot com>, <gdb at sourceware dot cygnus dot com>
- Subject: Re: non-blocking reads/writes and event loops
- From: Jim Ingham <jingham at apple dot com>
- Date: Wed, 14 Jun 2000 10:07:40 -0700
- CC: "\"Insight (GDB GUI)\"" <insight at sourceware dot cygnus dot com>
on 6/12/00 6:47 PM, Todd Whitesel at firstname.lastname@example.org wrote:
>> The thing that needs to be decided is how far GDB should be pushed to
>> address this problem. Should GDB continue to be pushed to the point
>> where everything is event based or should, the current compromise remain
>> where a GUI is unable to exploit GDBs event-loop.
> I am a advocate of long-time eventification. We should not create a mess
> in an attempt to do it quickly, but it should remain a long-term goal.
> The flexibility that we gain in doing so will pay us back later.
I heartily agree!
> In particular, I think it is extremely inappropriate for GDB itself to
> require threads. That would, in principle, be about as bad as allowing
> parts of GCC to require a working C++ compiler...
That was also the conclusion we came to when Andrew, Elena et al were coming
up with the *-async targets. I don't think that we should solve the problem
of making gdb non-blocking by putting everything in separate threads.
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.