On Fri, 7 Feb 2003 14:44:58 +0100, Bodo Moeller wrote:
>> It is almost always an error to use 'select' with non-blocking
>>sockets.
>Er, why do you think so? It's pretty standard to use 'select' (or
>'poll') with non-blocking sockets to avoid busy waiting.
You either can block or you can't. If you can block, why are you
calling 'select'? Why not just block in the read/write function? If
you can't block, you can't call read/write on a non-blocking socket.
So what's the scenario where calling 'select' on a non-blocking
socket is useful? All that happens is if you encounter an unusual
situation where something changes in-between your call to 'select'
and your call to 'read', 'write', 'accept', or whatever, your program
stalls in the I/O function, possibly for a very long time.
Find me the standard that says that if 'select' says you can write
to a socket, there must continue to be buffer space available in the
future by the time you get around to calling 'write'. You won't find
it.
If you know the internals of 'select' on a particular platform, you
may happen to know that this is safe to do. But if you're trying to
write portable programs, you have to follow the guarantees that
standards like SuS give you. What standard says an implementation
can't shrink the send queue after 'select' returns a write hit? What
standard says an implementation can't remove a connection from the
'accept' queue if it's aborted by the far end before it's been
'accept'ed?
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
