David Schwartz wrote:
Which part of "For other sockets, readability means that queued data is
available for reading such that a call to recv, WSARecv, WSARecvFrom, or
recvfrom is _guaranteed not to block_." do you not understand?
It means a hypothetical concurrent call, not a future actual call.
There is simply no way the implementation can assure that data will be
available in the future, and in practice, it does not.
Then why in the world does select() even exist?
Imagine if there was a call that waited until the size of a file was at
least X bytes. It might be reasonable to say that the function returns when
a call to 'stat' is guaranteed to return a size larger than X for the file.
This doesn't mean that a *subsequent* call to 'stat' will find the size to
be larger than X. It means that at the moment the decision was made to
return, a 'stat' call would have returned a size larger than 'X'.
Sockets and files are two different things.
Note that actual real-world applications have broken due to this
misunderstanding. I agree that your intepretation of the documentation is
quite natural; however, it is erroneous.
Like every other status-reporting function, Select reports on the status at
some hypothetical point between when you called it and when it returns. It
cannot guarantee what will happen in the future.
DS
Um...if only one thread in one process has access to the socket handle,
I don't see how you could say that. The OS is going to go back on its
_guarantee_ that there will be data available in the next recv() call
and thus block?
And you still aren't answering my original question.
--
Thomas Hruska
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
