> >> 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.
I'm sorry. It seems to me that you made a small mistake in your original post or your definition of "non-blocking socket" is different than other peoples. You said: "It is almost always an error to use 'select' with non-blocking sockets." All your arguments given in this letter and the next one indicate that you wanted to say: "It is almost always an error to use 'select' with blocking sockets." (And I completely agree with this one) Or you have got the definition of "non-blocking socket" vice-versa. Look: > 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. This description fits exactly the situation when you call select on a blocking socket. Kernel can remove the aborted connection from accept queue and then accept will block. That why you want to use non-blocking sockets. Arne ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
