Thor Simon wrote:

> On Sat, Sep 29, 2007 at 03:11:18PM -0700, Davide Libenzi wrote:
> >
> > 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);

> This is not how select() works, but I assume you know that and are
> intentionally writing pseudocode.  However, what it elides is that,
> generally, applications using select() for nonblocking I/O are managing
> many sockets at once.  In practice, selecting on one of those sockets in
> both directions when you only care about one direction is almost zero
> cost.

Selecting on one of those sockets repeatedly in a direction for which it is
ready but for which you do not intend to perform an operation has maximal
cost. It will push your CPU consumption right up to 100%.

> Obviously, if you're shutting down, and the socket's returned ready for
> write once, you select only for read; the corresponsing condition is true
> in the opposite direction.

Umm, why? Just becuase you're still shutting down doesn't mean the OpenSSL
library is still trying to perform the same operation. Maybe before it was
trying to send its shutdown but now it's waiting for a response. Maybe
before it was waiting to finish a renegotiation and now it needs to send an
indication to the other side that the connection should be shutdown.

> Yes, it's a stupid API.  Yes, it's a nuisance to work around it.  But
> changing it is _still_ going to break people's code that switches on what
> were, previously, the only possible error codes that could be returned
> during a shutdown -- which didn't include WANT_READ and WANT_WRITE.

Please explain how you work around it. I think you have some hacks that
"just happen" to work, but no sound way that's guaranteed to work. If you
select for write, you can spin forever. If you don't select for write,
you're simply hoping that OpenSSL didn't actually need to write data.

> I can easily fix the code _I_ care about to conform to the (better) API
> you're proposing.  But I don't think that's a particularly good reason to
> break other people's code, and pretending that it was impossible to get
> the job done isn't tremendously helpful either; there really is a lot of
> code out there already that uses non-blocking BIOs despite all their
> warts (see my complaints about the need for SSL_select() from several
> months ago for another example) and that code really, truly does manage
> to shut down sessions without spinning.

This is one of the many reasons I always use BIO pairs.

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to