> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
