> David,
> Please post a link to a manpage or other documentation that
> justifies your
> description of select.
I posted a link to the SuSv2 description of 'select'. There is no
guarantee
there that a future operation will not block.
http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
> Your stat analogy is incomplete; stat returns the true file size, in the
> absence of other external factors, such as another process (or thread)
> doing something. Select makes the same guarantee, under the same
> circumstances. Note that select predates threads.
Right, but there are external factors, packets might be received or
timers
might expire. There can also be odd quirky factors, like the subsequent
operation may not be asking for precisely the same thing 'select' test for.
We assume that a 'read' or 'accept' is the prototypical function to
follow
a 'select' for readability, but there are also other reading functions. If
'select' really was supposed guarantee that a future operation would not
block, a subsequent 'recvmsg' secifying MSG_WAITALL would have to be made
non-blocking. Can you name *any* implementation that does that?
Either it's possible to match 'select's with "subsequent operations" or
it's not. If it is, why do no implementations match the 'select' to the
recvmsg(MSG_WAITALL) and make it non-blocking? If it is not, how can
'select' provide a guarantee about an operation that cannot be identified?!
> Your idea that the semantics of TCP might change, invalidating current
> implementations, is also not valid -- no fair to conjecture about
> implementations not written for protocols not specified.
Yes, it is definitely fair. That's why we have standards -- so we know
what
is guaranteed not to change and what can change in the future and must not
be relied on.
> Nevertheless, from the beginning, there are various buggy implementations
> -- primarily because of non-BSD implementations (can you spell STREAMS?
> :), so therefore it's always safest to use non-blocking and check for
> EWOULDBLOCK. Note that setting non-blocking itself is a portability
> hassle.
It has now been standardized, though it can still be a hassle if you
have
to support systems that are not standardized.
People once assumed that 'read' hit on a listening socket guaranteed
that a
future 'accept' would not block. We now know that assumption is incorrect
but at the time, nobody could think of any way it might break. The code,
however, was always broken. It relied on a guarantee that it did not have
when there was a way to get the guarantee it needed.
It really comes down to this: if behavior we require is not guaranteed,
is
it an error to assume we'll get it anyway without asking for it if there's a
simple standardized way to ask for it? My answer is "yes". (For those
systems that follow the standard that provides the way to get the behavior
and does not require the behavior without using that way.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
