Bill Janssen <bill.jans...@gmail.com> added the comment: What's happening is that the new state returns from SSL_shutdown() are saying, "the shutdown you asked for didn't happen this time, but call me again when you get a chance. And here is a hint about why it didn't happen, so that if you are sophisticated enough, you can get better information about whether subsequent calls to shutdown() will succeed."
Given the underlying architectures we are dealing with, is it possible to handle this properly? Basically, what the SSL_shutdown code is saying is that all higher-level event loops should understand an additional kind of event, "shutting down the SSL socket", on a par with "read bytes" and "write bytes". But our event processing handlers, like asyncore, basically only deal with read and write. I don't see how to tell them that a "close" operation should turn into a "read" or "write". We could also think about turning non-blocking sockets into blocking sockets, by adding a time.sleep(0.1) and re-calling SSL_shutdown(). But maybe the right thing to do would be for the write handler in the asyncore loop to catch this, and re-try the write when it gets a chance. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8108> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
