delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
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= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=+c6g9lZKG | |
CjITMno7k/8oBPPhPk=; b=k4CGRMmVMXjfUfcoVJaeIzcQBqYknsN8+swTYk5K4 | |
XSZy9LZbhGW4p3A4vjbeG8mhWJTboAxEoL1fqJoWaSSXHjMIamcoD9Vzxw0Fy+wA | |
uChKA4J/RZZ1JNK93umG8JLLtrBDGw3IPrMoZp0CO0DP1AZFcHd1fz+yrPrEAg+o | |
tY= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Virus-Found: | No |
X-Spam-SWARE-Status: | No, score=1.3 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 |
X-HELO: | mx-out-manc2.simplymailsolutions.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> |
MIME-Version: | 1.0 |
X-IsSubscribed: | yes |
X-MIME-Autoconverted: | from quoted-printable to 8bit by delorie.com id t2HMreUg005423 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |