This is the mail archive of the gdb-patches@sourceware.org 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]
Other format: [Raw text]

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


> From: Pedro Alves <pedro@codesourcery.com>
> Date: Fri, 17 Oct 2008 00:34:50 +0100
> 
> For non-stop mode, however, I'll need two other event sources registered in
> the event loop, that are independant of the remote communication, as you'll
> see in the patch I'll post soon.  The easiest way to get us a select'able
> file descriptor with the properties we want, is a pipe.  We register the
> read end in the event loop, and write something to the write end whenever
> we have something interesting to tell the core about.

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.

> Now, the problem with remote.c, is that it is built on all hosts, and it
> happens that on Windows, the file descriptors returned from `_pipe'
> are not waitable on.

Right, because the above design is also horribly non-portable.

> 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.


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