On Sat, 29 Sep 2007, Thor Lancelot Simon wrote:
> > As far as changes to the existing behaviour, blocking BIOs will never get
> > the new error code (<0). And noone could have used the non-blocking BIOs
> > in a sane way, with the current behavior
> > (lack of proper WANT_READ/WANT_WRITE).
>
> I'm sorry, but your assertion about WANT_READ/WANT_WRITE is false. In
> practice, the way it's been for many years is that if you get
> SSL_ERROR_SYSCALL back, you simply put the socket in your select set for
> all event types (read/write/exception). Yes, it is a rough spot in the
> API. Yes, in an ideal world, it would never have worked this way. The
> problem, as with so much else in OpenSSL, though, is that there's a lot
> of application code out there by now that knows how the API actually
> works -- not how it _should_ work, but how it _does_ -- and adding
> new error returns that weren't possible before will break some of that
> code.
Heh? Wait for read&write? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code == SSL_ERROR_SYSCALL) {
select(SSL_get_fd(ssl), RDWR);
continue;
}
...
}
Now consider a typical case, where, just for example, our notify-close is
already gone and we're wating for the peer notify-close. Output buffer are
empty, so the select(RDWR) returns immediately every time you call it.
Same happens in the case where our output buffer are full, we're trying to
send our notify-close, and the peer one is already on our socket buffers.
So, how much CPU is that gonna eat?
It'd be great to see how your code sanely handles SSL_ERROR_SYSCALL with
non-blocking BIOs.
- Davide
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
