This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients amaury.forgeotdarc, barry, ddvoinikov, exarkun, flox, giampaolo.rodola, janssen, jimsmyth, josiah.carlson, josiahcarlson, pitrou, qwavel, rhettinger, srid
Date 2010-03-22.14:57:46
SpamBayes Score 0.000147722
Marked as misclassified No
Message-id <1269269973.3782.5.camel@localhost>
In-reply-to <>
> The patch seems ok to me. This is how it was supposed to be in the
> first place if behaved as expected with non blocking sockets.

Ok, patch applied.

In light of the recv() and recv_into() implementation change, I also
think we should enable SSL_MODE_AUTO_RETRY for SSL sockets. It prevents
blocking read() calls from getting SSL_ERROR_WANT_READ at all.
(previously, we would loop manually in recv() and recv_into(); letting
the C OpenSSL runtime do it for us is certainly more efficient)

See description in


        Never bother the application with retries if the transport is
        blocking. If a renegotiation take place during normal operation,
        a SSL_read(3) or SSL_write(3) would return with -1 and indicate
        the need to retry with SSL_ERROR_WANT_READ. In a non-blocking
        environment applications must be prepared to handle incomplete
        read/write operations. In a blocking environment, applications
        are not always prepared to deal with read/write operations
        returning without success report. The flag SSL_MODE_AUTO_RETRY
        will cause read/write operations to only return after the
        handshake and successful completion. »
Date User Action Args
2010-03-22 14:57:49pitrousetrecipients: + pitrou, barry, rhettinger, josiahcarlson, exarkun, amaury.forgeotdarc, janssen, giampaolo.rodola, josiah.carlson, ddvoinikov, srid, flox, qwavel, jimsmyth
2010-03-22 14:57:46pitroulinkissue3890 messages
2010-03-22 14:57:46pitroucreate