Performance: fhandler_socket and ready_for_read()

Christopher Faylor
Tue Jul 30 19:01:00 GMT 2002

On Wed, Jul 31, 2002 at 02:44:29AM +0100, Conrad Scott wrote:
>"Christopher Faylor" <> wrote:
>>You don't have to worry about non_blocking or returning the base class
>>because you know that it is not intended to be called for the
>>non_blocking case and you know that sockets are "slow" devices.  So I
>>think this should only be gated on whether we're lucky enough to be
>>using winsock2.
>I realised that when I wrote it but I had some sort of aesthetic
>criteria reaction: like not relying on the caller to be doing the right
>thing; or, like making the change as precise as possible.

But we already rely on the caller to be doing the right thing in the
base class.  The reason for this is that the non-blockingness of an fd
has nothing to do with whether the method can correctly deal with

>Also if the setting of the NOEINTR flag is going to overridden
>completely like this, perhaps set_r_no_interrupt() ought to be
>virtual and overridden in fhandler_socket to generate an error,
>just in case someone one day calls that and expects it to have
>some effect?

Probably but since I just made get_r_no_interrupt virtual 30 minutes
ago, it obviously wasn't a design goal previously.  :-)

Now that you mention it, though, this could be handled (correctly?) by
calling set_r_no_interrupt whenever we first create a socket iff
winsock2_active.  I think putting this in the fdsock function would
catch this.  This means that I didn't have to virtualize this method.

I think this is a Corinna decision now.  Sorry.  I'm pretty tired and
not thinking too clearly.

I think we're narrowing it down, though.  :-)


More information about the Cygwin-patches mailing list