Mail Archives: cygwin/2007/10/24/11:59:52
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/
- Raw text -