Girish Venkatachalam wrote:
I don't know what is supposed to happen in theory, but
in practice I have found select() to be quite a
disaster in informing me when a socket becomes
writable. I have seen this on both Linux and FreeBSD.
select() is very useful and an elegant solution for
multiplexing sockets and doing non blocking IO.
However it is useful only for getting to know when a
socket becomes ready for read.
select() / poll() for writablity on a not-yet-connected socket works
reliability. Once it becomes connected (or an error occured because it
can't get connected) its writability will be signalled. Your
application calls connect() again this time it returns 0 and you stop
waiting for connection now and start using the socket to convey data.
What is the problem with select() more often than not signalling
writability, this is correct. You have to also test if you have data to
give select too, so the idiom would be like:
FD_ZERO(&fdwrite);
if(i_have_data_to_write)
FD_SET(fd, &fdwrite);
If you dont have data then you don't ask select() to signal writability,
because you don't care about it.
I have seen code in which select() is used for getting
to know pending writes. But this is only when we have
written and for some reason the write operation does
not write the full amount. In this case, we are
interested when the socket becomes writeable bcoz we
want to finish our write.
The "and for some reason", is because the way socket IO does resource
accounting and flow control.
Other stratagies like WIN32 Overlapping I/O require the application to
do its own resource accounting, if it didn't it may well eat the entire
RAM of the machine up if the data source (file on disk) can read data
faster than the data target (other end of network connection) can sink
the data.
With sockets this problem doesn't exist the kernel arbitrates the flow
control and resources to enforce that flow control by creating back
pressure right into the application.
But if you naively check for write condition on a
socke t with select() you will find that it always
returns that the socket is writeable.
Only when (the socket is connected OR in error state) AND the kernel has
the minimum low water mark of buffer space free to accept new data.
These are all useful circumstances when an application would want to
service the socket to do more work or be notified of an aborted connection.
But I have always found non blocking IO to be a very
advanced use of sockets and my advice will be that you
should not attempt if you don't know what you are
doing .
This is a shame, they really aren't that scary.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
