Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Date: Wed, 31 Jan 2001 13:16:00 +0100
From: Corinna Vinschen <cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Possible problems in select() under Win95/98/ME
Message-ID: <20010131131600.G13349@cygbert.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <004801c08b79$cb06d460$1300a8c0 AT veejoe DOT com DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <004801c08b79$cb06d460$1300a8c0@veejoe.com.au>; from vic.cross@veejoe.com.au on Wed, Jan 31, 2001 at 09:34:37PM +1000

Can't see these effects on W2K. Could be a 9x/ME problem. Note that
the below behaviour would cause failing inetd which definitely works
even on 9x/ME so I assume a border case.

Please create a _minimal_ testcase to reproduce the behaviour.
BTW: Which version of Cygwin?

Corinna

On Wed, Jan 31, 2001 at 09:34:37PM +1000, Vic Cross wrote:
> 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple