This is the mail archive of the gdb@sourceware.cygnus.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]

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.

(deftly dancing)

>> 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
>intolerant :-)

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.

cgf

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