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.

>                       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.

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.

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.

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.

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

Reply via email to