> IMO, it's not reasonable since the application could use something > different than select.select(), like select.poll() or something else > again. As I said before, you can do away with select or poll altogether if you write a state machine for your asyncore dispatcher. Asyncore will tell you when you can read or write the socket; you just need to know what to do with that information. > I guess that the best thing to have in such case would be having an > "ssl-ized" wrap of the socket which follows the same behaviour of a > classical non-blocking socket, then it would be up to the application > deciding what to do with it. That's what you get if you use "do_handshake_on_connect=False". Your application is expected to do the SSL handshake in its own time. You can do it whichever way you want, as long as you keep calling "do_handshake" appropriately until it fails to raise an error. I think it's simpler to let the SSL module do it, even though it comes at the expense of blocking the thread till the handshake is complete. > That way the asynchronous application which wants to switch to a > secure connection would just need to wrap the socket by using > ssl.wrap_socket() without altering the existing code. That's essentially what happens already. The question is whether the SSL setup code is allowed to block the non-blocking socket till the SSL handshake is complete. Bill
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4