X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 24 Oct 2007 17:59:26 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: strange select() and recvfrom() behaviour
Message-ID: <20071024155926.GO20400@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <46567 DOT 131 DOT 220 DOT 7 DOT 1 DOT 1193238723 DOT squirrel AT webmail DOT iai DOT uni-bonn DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46567.131.220.7.1.1193238723.squirrel@webmail.iai.uni-bonn.de>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Oct 24 17:12, Marcell Missura wrote:
> Hello,
> 
> I observed some strange behaviour on Windows when I was using a select()
> and recvfrom() combination to implement a socket listening behaviour with
> timeout. Here is an extract from a test program.
> [...]
> First of all, you might notice that I'm trying to have select() time out
> for 1 millisecond. This doesn't work, it times out for 10 ms and that
> seems to be the lower limit. This issue was actually discussed recently.

Cygwin's select has to do a lot of stuff to be able to work with
different types of file descriptors, in contrast to the Winsock select
which only works on sockets.  It's easily possible that the overhead
disallows smaller timeouts than 10ms.  Having said that: This is by
design and allowed behaviour per SUSv3(*):

 "Implementations may also place limitations on the granularity of
  timeout intervals. If the requested timeout interval requires a finer
  granularity than the implementation supports, the actual timeout
  interval shall be rounded up to the next supported value."

> The other thing is that after having sent a UDP packet of 6 bytes to the
> program this is the output it produces:
> 
> 1   6 bytes received
> 1   -1 bytes received
> 1   -1 bytes received
> 1   -1 bytes received
> 1   -1 bytes received
> 1   -1 bytes received
> 1   -1 bytes received
> 
> The first time select() returns correctly with 1 and I read all 6 bytes
> from the socket. The buffer is large enough. After that select() returns 6
> more times with 1 (clearly not a timeout!) and lies to me about the socket
> being ready for ready, but recvfrom() sets it right with a return value of
> -1;

SUSv3 has this to say(*):

 "A descriptor shall be considered ready for reading when a call to an
  input function with O_NONBLOCK clear would not block, whether or not
  the function would transfer data successfully. (The function might
  return data, an end-of-file indication, or an error other than one
  indicating that it is blocked, and in each of these cases the
  descriptor shall be considered ready for reading.)"

So, to me, the above behaviour looks correct, especially considering
that you didn't mail a complete, selfcontained testcase, which builds
and runs OOTB, and which allows to reproduce a potential misbehaviour.

> The same thing does not happen in a pure linux environment with exactly
> the same Code.

While we're trying to get Cygwin to behave as much as Linux as possible,
this doesn't automatically mean that Cygwin's behaviour is incorrect.
A bit of actual proof would be nice.


Corinna


(*) http://www.opengroup.org/onlinepubs/009695399/functions/select.html


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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