David Schwartz wrote:
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?
The same reason every status-reporting function exists. Sometimes
information about the past is very useful. It just doesn't guarantee the
future.
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.
I agree. I'm just talking about what the wording in the documentation
means. It is not guaranteeing future behavior but explaining what
past/present behavior happened.
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.
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?
Yep. Remember, 'select' is protocol-neutral. With UDP, a packet might be
dropped after 'select' returned but before you get a chance to call
'recv'. Some other protocol might allow unreceived data to be cancelled by
the other end.
And you still aren't answering my original question.
Which question? If the question is how you can guarantee that an operation
on a blocking socket will not block, the answer is that you cannot do so.
Many have tried, failed, and caused real problems as a result.
DS
Hmm...interesting. Essentially what you are saying is "If one thinks
they need to use select() on a blocking socket, use non-blocking sockets
instead. And only when non-blocking sockets are insufficient, use
select() (i.e. to avoid a CPU-eating polling type of situation without
sacrificing I/O performance that would be associated with sleep())."
Yes? If so, the above paragraph or something similar should be
documented somewhere important (e.g. the manpages). The "many have
tried, failed, and caused real problems" issue you state indicates
public documentation is not clear. The discussion of a SSL_select()
comes up every so often on this list and I believe this very issue is
the root cause.
Not every day I learn something new. Though I'm slightly horrified
because my code base is extensive and I do quite a bit of socket
programming...and I've been doing it wrong for about 7 years. This is
apparently going to be a LONG weekend.
--
Thomas Hruska
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
