Darryl Miles wrote:
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.
While I don't entirely agree with David either, I see his point about
using select() as only a performance stop-gap in non-blocking code and
never assume that the next recv() will succeed to be non-blocking in
blocking code after a select() (i.e. if you want non-blocking sockets,
use non-blocking sockets instead of trying to fake them - that's what
they are there for).
I've spent the past four days re-writing large chunks of code and I have
to say, the end product is turning out to be a LOT cleaner and simpler
than the original code. The hacky "feel" of the code is vanishing as if
I've finally got it right. I've always thought the way I wrote socket
code was a bit "off" but couldn't put my finger on why. So while David
could be wrong, my code is clearly being written correctly. Basically,
David opened my eyes to an alternate approach to socket programming that
is shorter in length, more performance-friendly, AND completely
eliminated my thoughts that a SSL_select() should even exist*. I can't
really argue with that.
* It makes complete sense now as to why there is no need for a
SSL_select(). Before now I always thought it was odd that a
SSL_select() didn't exist. This list occasionally receives requests for
a SSL_select() function. That is an indicator of improperly-written
socket code.
--
Thomas Hruska
Shining Light Productions
Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/
Ask me about discounts on any Shining Light Productions product!
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
