thread safe SMTP module

Aahz aahz at
Thu Mar 8 17:29:41 CET 2007

In article <mailman.4657.1173039582.32031.python-list at>,
Gordon Messmer  <yinyang at> 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":
>"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 (aahz at           <*>

"I disrespectfully agree."  --SJM

More information about the Python-list mailing list