DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-transfer-encoding:mime-version; q=dns; s=default; b=T/T
	d5T6orkXgObjcJecTNFlqX6i2Vw03bMCHcnL1PzWTju/wxDAj267knuqRMgRF1ve
	uW6K2aA/XOz8BAyQ3RDy8D+EkU4NRc3d6qLuloQR1h9QNLxGO4ChTfnGVX/6CQGq
	QXZRkNF0PIIDqjDvmuoKJTZL8IktB+2NPdwL4QcM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: Matthew Bromley-Barratt <matthew AT twobravo DOT org DOT uk>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Alternative implementation of select()?
Date: Tue, 17 Mar 2015 22:52:50 +0000
Message-ID: <5292189c1f6a46bfb905a4f31b5665b7@SHA-EXSP2-MBX21.exsp2.ifeltd.com>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello all,

If I've read the code right, the implementation of select()
in select.cc sets up a thread per file descriptor. Each of
these threads polls their file descriptor looking for events
that might have occurred. 

I also remember reading a long time ago (I cannot find it
now) comments from the original developers about the
difficulty of implementing select() on a Windows platform
because Window's own does not support pipes, ttys, etc. The
comments made it clear that the developers disliked being
forced to use a polling thread per file descriptor and the
inevitable inefficieny that resulted!

Win32 Read of Zero Bytes 
========================
I came across a snippet of information that might allow a
more efficient implementation. In short, in the win32 API
you are able to start an asynchronous read of a socket,
pipe, etc. What MS does not say in any of their
documentation is that the async read can be called for a
length of zero bytes, but it will still block until some
data arrives. It will then return zero bytes.

I'm afraid I've not tried it out myself anywhere, but it
would be very easy to do so.

If true, that would allow the use of a routine like
WaitForMultipleObjects() to wait for asynchronous reads on
all sorts of inputs (socket, pipe, tty, etc). The idea is
that when one of the async reads returns it will have done
nothing at all to the data that has arrived. The data will
still be in place in the socket buffers (or whereever) for a
normal read to return.

On the face of it this would seem to be ideal behaviour for
implementing the readfs part of select(). There are some
limitations in that approach; WaitForMultipleObjects() is
limited to 64 objects.

Win32 Write of Zero Bytes?
==========================
So if an async read of zero bytes does behave that way, one
wonders if a write of zero bytes will wait in a similar way.
If so, the writefs part of select() could be implemented in
the same way.

Worth it?
=========
I cannot answer that. I don't hear too many people
complaining about the existing implementation of select().

I've also not an answer for the last part of select().

Any thoughts?

Matthew

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple