generic `struct serial' interface pipe for remote non-stop

[Pedro Alves]

On Friday 17 October 2008 11:21:27, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>

> Forgive me, especially if I talk out of ignorance or misunderstanding,
> but isn't this a horrible design?  We need to communicate to the event
> loop that some event happened, and we do that by opening a pipe
> between one part of GDB and another, and talk to ourselves via that
> pipe?
> 
> Can't we instead register with the event loop some callback that would
> tell the loop that an event arrived?  Heck, even raise-ing a signal
> would be better.
> 

Believe me or not, I had just changed to using pipes very
recently ...  I was using the asynchronous signal handling mechanism
already in place, until I found out that it wasn't sufficient
for my purposes, so I thought that reusing pipes was the most
expedite way to solve this issue.  I was also avoiding touching
the event loop design, which is heavilly file descriptor based.
Read through event-loop.c.

> > For go32/djgpp or for unix hosts that don't have socketpair, I
> > just bail out with ENOSYS.
> 
> Does that mean that some feature that could have worked for DJGPP with
> a different design, will now be broken by design?  If so, I'd like us
> to look for alternatives.
> 

I can't honestly, seriously believe that anyone would be so masochist
enough as to be doing non-stop cross-debugging from DJGPP.  And, it's
not like you couldn't implement in-process pipes on DJGPP, and
implement a gdb_select on DJGPP too.  We do this for Windows.

That being said, I took a step back, and relooked at the problems I was
having with async signals handlers, which is a mechanism to register a 
callback function in the event-loop.  Notice that the currently event
loop design is heavilly based on waitable file descriptors, with async
signal handlers being a secondary input event source.

So I came up with the attached patch to adjust it to my needs.

The biggest problem the attached patch solves is:

 - Since async signal handlers are always checked before polling the
   file descriptors, I can easily starve the file descriptor based
   sources.  E.g., if I place several threads displace stepping a
   breakpoint, forcing continuous remote traffic, the CLI becomes very,
   very unresponsive, unusable really.  This is because stdin itself
   is registered as a monitored (via select/poll) file descriptor.

 To solve this, I adjusted the event loop to give equal priority to
 all event-sources (timers, async signal handlers, monitored file
 descriptors).  The async signal handling was changed to instead
 of immediatelly calling the associated callback, it installs an
 event in the "ready" queue, just like the file-descriptor and
 timer based sources.  I then make sure that I poll each of the
 possible event sources once (select/poll with timeout 0 too).  If
 if no event is found ready, then, we go blocking waiting for one
 in select/poll.

I can sucessfully debug a non-stop linux gdbserver from both
a linux host and a Windows (mingw32) host with this.

The remote.c changes below apply on top of the non-stop support
patch I sent yesterday, and it's what I used to test, shown here
so you could see what was required that change, in case you're
curious about it.

Do you think it is a better alternative?  I can't think of a reason
this wouldn't work on DJGPP.

-- 
Pedro Alves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unpipes.diff
Type: text/x-diff
Size: 23253 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20081017/3aff3d57/attachment.bin>