This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 00/17] Merge event loop implementations
- From: Tom Tromey <tom at tromey dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Sun, 24 Feb 2019 10:25:55 -0700
- Subject: Re: [RFC 00/17] Merge event loop implementations
- References: <20190224165153.5062-1-tom@tromey.com> <83sgwdnm6r.fsf@gnu.org>
>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
Eli> The problem here is that Windows' implementation of 'select' works
Eli> only on sockets, and wants HSOCKET handles instead of file
Eli> descriptors. If you feed it a file descriptor, it won't work, even if
Eli> the descriptor is for a socket.
Thanks.
I am still not sure what to do. Move the mingw-hdep select code to
common? Or is it better to reintroduce gdb_fildes_t and use it
everywhere? The former seems simpler I suppose, but the way that the
mingw-hdep select implementation relies on readline gives me pause.
Though perhaps that code will be removed in the readline upgrade, when I
get back to that? So one idea might be to try to land that first.
Eli> I cannot really tell, by reading the patches, what code would
Eli> gdbserver on Windows use after this series, so I don't know whether it
Eli> will be broken or not. But one thing I do see is that mingw-hdep.c
Eli> doesn't support waiting on write descriptors, whereas gdbserver's
Eli> event-loop.c seems to support that.
Both event loops claim to support it, but in practice it isn't actually
exposed via the API -- the only exposed API is add_file_handler, which
doesn't allow for requesting a write notification. All the write stuff
is dead code.
One other thing I forgot to mention is that maybe it would be nice to
just remove gdb's event loop entirely in favor of something like
libevent. Though of course it is a pain to introduce a new dependency.
Tom