This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: Performance: fhandler_socket and ready_for_read()
- From: Christopher Faylor <cgf at redhat dot com>
- To: cygwin-patches at cygwin dot com
- Date: Tue, 30 Jul 2002 20:29:10 -0400
- Subject: Re: Performance: fhandler_socket and ready_for_read()
- References: <07f001c2381e$43118070$6132bc3e@BABEL>
- Reply-to: cygwin-patches at cygwin dot com
On Wed, Jul 31, 2002 at 12:10:13AM +0100, Conrad Scott wrote:
>Attached is a socket patch that can make some programs by as much as 50
>times quicker.
>
>In looking for something else, it struck me that there doesn't seem to
>be any reason for the fhandler_base::ready_for_read() method when
>reading from sockets. All that the method seems to be doing is
>checking for signals while waiting for data to arrive on the relevant
>fhandler object (eventually it calls peek_socket() which does a
>select() on the socket). The fhandler_socket::read() method already
>handles signals happily (if the socket is blocking and winsock2 is
>available) since it uses an overlapped read and then blocks on the
>socket event and the signal_arrived event.
>
>Assuming that there is thus no need for this call to ready_to_read()
>for sockets (and please tell me if I'm wrong here), the following patch
>provides an stubbed fhandler_read::ready_for_read() that does nothing
>when that is valid.
If sockets are already testing for signals then ready_for_read is
redundant and even incorrect.
I think the actual way to fix this is to add a get_r_no_interrupt method
to fhandler_socket. This avoids a call to ready_for_read. This wasn't
previously possible since this wasn't a virtual method but now it is.
Unless you disagree, would you mind just adding a get_r_no_interrupt method
to fhandler_socket, using the same criteria as your ready_for_read stub?
Thanks for finding this, by the way. A speed improvement in socket handling
is very welcome. Sounds like it is time for a 1.3.13 release.
cgf