> > Same thing, no guarantee about what an actual future operation will
> > do. By
> > "would not block", they mean a hypothetical operation taking place at
> > the
> > time the indication is given to you.
> No. That's stupid. It's useless.
Not at all. It's the same as every other status reporting function.
> By 'would not block' they mean 'if
> nobody else messes with the descriptor, the operation would not block.'
The operation you didn't perform because you are performing a 'select'
at
the time. Why would they say "would not block" instead of "will not block"
if they meant an actual future read call?
Tell me, if this is correct, why does no implementation assure that a
subsequent recvmsg(MSG_WAITALL) doesn't block? And consider if you decided
you want to do that, how you would figure out which 'recvmsg' calls were
subsequent to a 'select' and which weren't in a general way.
> Your meaning means that select is absolutely *useless* to a programmer
> unless the socket is set to non-blocking mode;
No. Only if their intention is to never, ever block.
> there is no mention in the
> select manpage that the socket must be in non-blocking mode.
It doesn't have to be. You can set it non-blocking later or maybe you
really do want to block until application-level data is ready. The
implementation cannot know what you want unless you tell it.
> Further,
> since a non-blocking selectd can return EWOULDBLOCK for any operation,
> select on non-blocking becomes nothing more than an optimization hint to
> avoid a read system call.
That's a good, defensive way to think about it. Since things really can
change in-between when 'select' returns and you call a read function.
If you really believe what you're saying, you would have to say that any
implementation that allows an 'accept' to block after a read 'select' hit on
a listening socket is broken. Otherwise, select is absolutely *useless* to a
programmer unless his listening socket is set to non-blocking mode.
Just as things can change on a listening socket, things can change on a
stream socket. Packets can be received. Timeouts can occur. Data that might
have been application may turn out to be protocol.
At one time, people thought nothing could change on a listening socket
and
they wrote code that operated on precisely the assumption you continue to
recommend. Their code broke because of a situation they didn't anticipate
but that was never guaranteed not to happen. You now go out of your way to
repeat that error.
Either a future operation is guaranteed not to block or it's not. The
assumption that it is guaranteed is falsifiable with many examples. The
examples are not all precisely on point, but they suffice to show you don't
have the guarantee.
And, of course, this very case is precisely on point. This very same
assumption broke in this very same code we are talking about. It broke
because 'select' was thinking "application data or protocol data" and his
read function was for application data.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
