[Python-Dev] ssl module, non-blocking sockets and asyncore integration
Bill Janssen
janssen at parc.com
Wed Sep 17 19:40:01 CEST 2008
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 <janssen at parc.com> wrote:
> Giampaolo Rodola' <gnewsg at gmail.com> 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/janssen%40parc.com
More information about the Python-Dev
mailing list