> > R. Stevens, Unix Network Programming, Volume 1, Second Edition, Section > > 6.3, page 153: > > > > 1. A socket is ready for reading if any of the following four conditions > > is true: > > > > a. The number of bytes of data in the socket receive buffer is greater > > than or equal to the current size of the low-water mark for the socket > > receive buffer. *** A read operation on the socket will not block > > and will > > return a value greater than 0 (i.e., the data that is ready to be > > read).*** > > That does not mean that you can issue any read operation at any later > time > and it's guaranteed not to block. It just means that at some instant > in-between when you called 'select' and when it returned, a hypothetical > 'read' operation would not have blocked. By the time you get the > information, it's out of date, just like 'access' and pretty much every > other status function. It uses the term "will" because it means at the time > the socket was determined to be ready for reading, not some later time when > you noticed that.
You are now introducing some weirdness into our little blocking world. Threads and other scary stuff. Yes, if a gremlin reads the data from the buffer between calls to select() and read(), the read() call might block. But if we assume that there is only one process with single thread using the socket, isn't it a valid assumption that if at some point during the select() call the data appeared in the buffer, there was *no way* for it to disappear from the buffer without us calling read()? As for your example with write() -- of course a write of 20Mb might block, but we are not talking about write(), we are talking about read(). They do have different semantics. Same goes to your mentions of accept(). After bringing in threads, write() and accept() calls into this discussion you have to either mention signals or accept that you are out of arguments. (Of course I used gremlins so we are even) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
