Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <004801c08b79$cb06d460$1300a8c0@veejoe.com.au> From: "Vic Cross" To: Subject: Possible problems in select() under Win95/98/ME Date: Wed, 31 Jan 2001 21:34:37 +1000 Organization: Veejoe Consulting Pty Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Hello there! I am working on a project which is developing both Linux and Windows versions of a program originally developed under Linux. Part of the program handles terminal IO from telnet clients. This part of the project has uncovered two apparent problems in the internal processing of select(), at least for TCP sockets. The usual process of building a file descriptor set (containing the file descriptors for the listener socket and any connected clients) and entering a blocking select() call works flawlessly under Linux, but under Cygwin the select() appears to ignore the connected clients -- that is, select() does not unblock for incoming data on a client, and a new connection must be initiated to force select() to unblock (BTW, the fd_set is rebuilt after every select() call). Calls to FD_ISSET() are successful for the fds for the connected clients with pending reads, just that select() didn't unblock. In an attempt to work around this, a non-NULL timeval was added to the call to select() to force the pop of the select() at half-second intervals. This workaround uncovered another problem in select() -- every time select() returns, a TCP loopback connection is created and sits in TIME_WAIT status until it ages out. Various methods and tests have shown that the spurious connection is *definitely* co-incident with the return from select(). Thinking that our code was at fault, we continued trying to debug. Until I started a telnet session from a Cygwin bash prompt on my WinME laptop, and found the same TIME_WAIT connections appearing at every keystroke I typed in the telnet session, and every response from the foreign host. From this, I'm assuming that telnet is using select() also, and the same problem is occurring there. For the moment, we have stopped trying to debug our code. Any thoughts on this? I have read the Cygwin FAQ on how select() differs from *nix platforms, but it didn't seem to imply that the call should be used any differently, just explaining some of the "under the covers" differences. One of our project members is severely impacted by this, the problem being so bad that his machine was running out of sockets after a short time running the program. He has since altered the registry to reduce the TIME_WAIT delay as a workaround, but we would prefer the issue resolved. Specific questions: 1) Why does select() appear to unblock only when the first fd in an fd_set becomes readable? 2) Why do we experience a spurious TCP loopback connection in TIME_WAIT status after every select() call? Thanks for any assistance that can be provided. Cheers, Vic Cross vic dot cross at veejoe dot com dot au -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple