Subj : Re: Threading and Timeouts
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Sat Jul 23 2005 02:00 pm

David Schwartz wrote:


>> BUT, while it is not correct to *base* an application on this assumption,
>> it
>> is correct to *exploit* it, provided a different outcome (i.e. read() on
>> a ready-to-read socket actually blocking) won't cause the application to
>> mis-function; as any error condition must not cause a correct program to
>> fail, then THIS error condition (blocking on a socket after select() has
>> said it's ready) must be correctly dealt too, or the consequences of not
>> dealing with it must be accurately known.
>>
>> Am I correct up to this point?
> 
>     So long as you understand that the function might block, then fine. My
> point is simply that the operation might block. If you don't mind, then go
> right ahead.
> 
>     DS

David, (or anyone else) how do this part of the standard interacts with the
select() function?

"""
 2.10.11 Socket Receive Queue

A socket has a receive queue that buffers data when it is received by the
system until it is removed by a receive call. 
"""

While select() does not ensures that a ready for receive socket will be
still ready a bit after, this should ensure that if the socket is found
ready for read because of incoming data, that data will be still available
later on.

Of course, there's the case in which the socket is found ready for read for
any other reason (i.e. socket close on remote side), in which it is still
unspecified what happens next (i.e. you may immediately see socket close
with a read or be forced to wait).

Also, this part doesn't explicitly says that, even if the data is ready on
the queue, read() has to return it without blocking... 

Can you confirm I am reading this part of the standard correctly?

Bests,
Giancarlo Niccolai

.