This is the mail archive of the
mailing list for the GDB project.
Re: non-blocking reads/writes and event loops
On Mon, Jun 19, 2000 at 03:01:08PM +1000, Andrew Cagney wrote:
>Nick Duffek wrote:
>> >So my vote is to eradicate ALL the blocking behavior, and make GDB a pure
>> >event driven application.
>> Does that include file I/O? Reading a core file over NFS could freeze a
>> GUI for quite a while.
>Some how, I suspect not. Some operations, such as reading/writing an
>executable will continue to be blocking. If an NFS partition freezes
>then I suspect a hung GDB is the last thing on the users mind :-)
>> I'd rather see the GUI problems solved by two processes:
>> (1) the GDB core, which talks to inferior processes;
>> (2) the user interface, which talks to (1) over a pipe using a
>> well-defined protocol.
>> [Credit to Chris Faylor and Jim Blandy for suggesting this approach.]
>FYI, the ``well defined protocol'' is called MI :-)
I think I suggested that this was the same mechanism that we had been
considering for future UI work.
>> The user interface could be a GUI, a command-line interface, Emacs, etc.
>> Pipes are non-blocking, so a GUI need never freeze due to blocking
>> debugging calls.
>> As far as I can tell, this provides all the benefits of fully
>> event-loopizing GDB without the cost of making GDB hugely more complex.
>Unfortunately, it avoids rather than solves the problem. One thing we
>found from MI is that even after you separate out the GUI, GDB, in the
>end, still needs to be 100% non blocking.
>Consider a GDBng (GDB 6) that is trying to talk to two (or more) active
>remote targets. The current remote.c blocks out all other activity
>while it is communicating with a single target. Just like it can
>currently block out the GUI, it would also block out the processing of
>those other targets. While the user is surprisingly tolerant of a 5-30
>second hiccup, the typical protocol tends to be be surprisingly
I don't think that Nick was suggesting going back to 100% blocking
behavior. In this case, if blocking I/O was the only thing available,
you'd need to fork another process.
I was thinking more of a process hive which communicated via shared
memory. So, there would be a main "gdb" which printed a prompt
and as many other dedicated processes as needed to control targets.
As far as NFS is concerned, I think that Nick was talking about the
noticeable lags that can occur when loading something like a core file
over NFS. The delay isn't necessarily a sign of a problem with NFS.
Maybe a user would expect a long delay in this case but I would think
that it would also be a problem for gdb.
If you assigned the "reading a core file" function to another process
then the lag could be circumvented.