> My first reaction was that this is a bug in the library, but I
> didn't feel
> very strong about it and would have accepted that this is just a bug in
> s_client. I like your argument about the library not having the right to
> make 2 blocking calls unless retry is set and now I'm back to thinking
> that this should be fixed in the library.
> I'm pretty confident that the fix (if it is feasible) is not going to
> break any correct application code.
> And I'm pretty confident that it is going to make app. engineer's life
> easier.
Why is the number of blocking calls significant? How are two blocking
calls
different from one?
If anyone thinks that 'select' or 'poll' guarantees that a future
operation
will not block, even if it's a single operation, that's just plain not true.
The only way you can guarantee that even one operation will not block is if
you set the socket non-blocking.
I can't quite see the point of not setting auto-retry. You make blocking
socket operations when you want to block until they can be completed. What
possible use would half-blocking be? To try as hard as possible to find the
corner cases where you think you won't block but then accidentally do?
Please show me the standard that says that the return value from
'select'
or 'poll' guarantees that a future operation will not block. It cannot be
done. Operations on blocking sockets can *always* block. That's why they're
called 'blocking sockets'.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
