In article <[EMAIL PROTECTED]>, Gordon Messmer <[EMAIL PROTECTED]> wrote: >Aahz wrote: >> >> Assuming you have correctly tracked down the problem area, I would call >> that a thread bug in Python. But my experience is that you simply have >> run into a problem with the socket. I would suggest that using >> socket.setdefaulttimeout() would work just as well. > >I believe that solution, also would not work. This note is included in >the socket documentation, regarding "timeout mode": > >http://docs.python.org/lib/socket-objects.html >"A consequence of this is that file objects returned by the makefile() >method must only be used when the socket is in blocking mode; in timeout >or non-blocking mode file operations that cannot be completed >immediately will fail." > >smtplib.SMTP uses file objects when reading SMTP responses. If I used >setdefaulttimeout(), then the socket would be in timeout mode and the >above note would be applicable.
Hrm. At this point, I would suggest taking discussion to python-dev; it has been too long since I looked closely at thread/socket behavior. >I am not at all above calling python's behavior a bug, except that it >seemed like a known behavior given the note in the thread documentation >regarding built-in functions that block on I/O. No, at this point I think this is neither bug nor about thread blocking on I/O. I think it's about sockets dying and the inability of sockets in blocking mode to recover. I have seen this kind of behavior in single-threaded systems. But it really needs someone who knows more than I do, and I think the first step here is to go ahead and file a bug report for tracking purposes. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM -- http://mail.python.org/mailman/listinfo/python-list
