> Linux:
> Three independent sets of descriptors are watched. Those listed in
> readfds will be watched to see if characters become available for read-
> ing (more precisely, to see if a read will not block - in particular, a
> file descriptor is also ready on end-of-file)
You'll notice that POSIX and SuS do not say this. The problem with this
is
that it seems like they're talking about some 'read' in the future, but
they're actually talking about a hypothetical concurrent read. The kernel
does not remember that it returned a read indication and issue a subsequent
read operation as non-blocking.
I think the authors of this man page simple misunderstood the standards.
When the standards at that time spoke of a read that "would not block" they
didn't mean after 'select' returned, they meant after 'select' was invoked.
(See below.)
> 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.
The 'select' function is just like any other status function. If you ask
the kernel the size of a file and it says 154,323 bytes, does that mean it's
154,323 bytes now? All it means is that at some point in-between when you
called the function and when it returned, the size *was* 154,323 bytes.
If there was some function that blocked until a file was a particular
size,
it could well be documented as "this function will return a succcess
indication if a 'stat' function would return the size waited for". It could
even say, "a match is generated if a 'stat' function will return the size
waited for." Does this mean a *subsequent* 'stat' function *must* return
that size? OF COURSE NOT, and it's sheer madness to suggest otherwise.
Seriously, these are harmful assumptions that break code. You simply
don't
have the guarantee you claim you have. It may be true some or most of the
time, but it's not guaranteed and it's error to rely on it. OpenSSL does
everyone a disservice by trying to force it to work somehow.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
