Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ was returned, things would block; that is, the "handle_read" method on asyncore.dispatcher was never called again, so the SSLSocket.recv() method was never re-called. There are several levels of buffering going on, and I never figured out just why that was. This (very rare) re-call of "read" is to handle that.
Bill Bill Janssen <[EMAIL PROTECTED]> wrote: > Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > > > In the meanwhile I noticed something in the ssl.py code which seems to > > be wrong: > > > > def recv (self, buflen=1024, flags=0): > > if self._sslobj: > > if flags != 0: > > raise ValueError( > > "non-zero flags not allowed in calls to sendall() > > on %s" % > > self.__class__) > > while True: > > try: > > return self.read(buflen) > > except SSLError, x: > > if x.args[0] == SSL_ERROR_WANT_READ: > > continue > > else: > > raise x > > else: > > return socket.recv(self, buflen, flags) > > > > I don't know the low levels but that while statement which continues > > in case of SSL_ERROR_WANT_READ seems to be wrong (blocking), at least > > when dealing with non-blocking sockets. I think the proper way of > > doing recv() here is letting SSL_ERROR_WANT_READ propagate and let the > > upper application (e.g. asyncore) deal with it. > > It's an interesting point. I'm not sure the underlying code will ever > raise this exception. Please file a bug report to help us track this. > > Thanks. > > 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/janssen%40parc.com _______________________________________________ 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
