In article <[EMAIL PROTECTED]>, Gordon Messmer <[EMAIL PROTECTED]> wrote: >Aahz wrote: >> >> That doesn't make any sense. Blocking I/O generally releases the GIL, >> which is the whole reason Python doesn't totally suck for threading. > >Nevertheless, among the caveats listed at >http://docs.python.org/lib/module-thread.html is: > >"Not all built-in functions that may block waiting for I/O allow other >threads to run. (The most popular ones (time.sleep(), file.read(), >select.select()) work as expected.)"
That's why I said "generally". >> There may be other thread problems, but I doubt that you have correctly >> analyzed their source. > >I subclassed smtplib.SMTP and replaced only the lines of code that had >to do with blocking IO (connect, send and receive operations). >Beforehand, python would occasionally lock up. Having made those >changes, python stopped locking up. I think the problem was pretty well >apparent. I can't pin it down to which one of those three operations >was at fault, and it may be that only one was. However, when I use >non-blocking IO, the application works. When I used smtplib.SMTP, it >didn't. > >I'm open to other explanations. 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. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM -- http://mail.python.org/mailman/listinfo/python-list
