Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
That is they never disappear unless the application permits them too.
What I mean by this is that the application is in 100% control of its
behavior and it has to take one of the following actions to allow a
indicator condition to be re-evaluated and therefore disappear:
* close the fd
* perform a single read()/write() (or any other similar operation, such
as recv()/send() etc..)
* issue another select() system call that asks to re-evaluate that same fd
Although David has theorized on the possibility of an operating system
receiving a UDP packet from another host, then indicating readability
via select() to the application, then the operating system decides to
chuck away that UDP packet (so its no longer there for a block recv() to
find immediately) this just does not happen. Maybe he is confusing tail
queue dropping with head queue dropping, where the head is the front of
the queue which the application sees next and the tail is the end of the
kernel's buffer space.
The challenge here is for someone to point out by way of pointing to
published source of a BSD socket implementation that will remove all
packets from the socket queue after having already advised a readability
indicator to the application.
Given that Window's BSD socket implementation clear states it will not
block there is no need to audit this specifically. There are numerous
other implementations freely available on the Internet to audit and
confirm this point.
In the file size example, I expect read to return 0. I made a
small test program and on linux (accidently?) it does not block
when reading a truncated file (actually, select even returns
`ready for read' on an empty file).
There is defined behavior for select() used on fd's that are files.
File I/O never technically blocks even though it could be argued that it
does take its time while waiting for the disk, but its always a finite
time to success or failure. <soapbox>This is one thing I hate about
most GUI apps, please do your file I/O in another thread, allow the
operation to be aborted from the GUI and update the GUI with the data
you needed from the file asynchronously.</soapbox>
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
