ssl.SSLWantReadError and ssl.SSLWantWriteError should inherit io.BlockingIOError.

Generic code that works with non-blocking sockets will stop working with SSLSockets.

Does anybody have any idea if SSLSocket.read() will need to write to the underlying socket or SSLSocket.write() need to read from it? AFAIK they don't.

Assuming that ssl.SSLWantReadErorr and ssl.SSLWantWriteError perfectly map to io.BlockingIOError (except during handshake).

> ssl.SSLWantReadError and ssl.SSLWantWriteError should inherit io.BlockingIOError.
> Generic code that works with non-blocking sockets will stop working with SSLSockets.

I'll have to think about that, but in any case non-blocking SSL code needs to be subtler than normal non-blocking code, because of this:

> Does anybody have any idea if SSLSocket.read() will need to write to the underlying socket or SSLSocket.write() need to read from it? AFAIK they don't.

Yet the documentation clearly tells you they can:
https://docs.python.org/3/library/ssl.html#notes-on-non-blocking-sockets

My questions are:
When will SSLSocket.recv() raise SSLWantWriteError?
When will SSLSocket.send() raise SSLWantReadError?

According to my very basic knowledge abou the protocol, this will never happen.

Le 23/08/2014 03:02, Hristo Venev a écrit :
> When will SSLSocket.recv() raise SSLWantWriteError?
> When will SSLSocket.send() raise SSLWantReadError?
>
> According to my very basic knowledge abou the protocol, this will never happen.

According to the OpenSSL docs:
"""As at any time a re-negotiation is possible, a call to SSL_write() 
can also cause read operations!"""
"""As at any time a re-negotiation is possible, a call to SSL_read() can 
also cause write operations!"""

I agree with Antoine, let's not subclass io.BlockingIOError.