> 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
