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 t
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
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.py
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 wa
In article <[EMAIL PROTECTED]>,
Gordon Messmer <[EMAIL PROTECTED]> wrote:
>
>I believe that I've seen this discussed previously, so maybe there's
>some interest in it. I wrote a threaded mail filtering framework
>a while ago, and one of the modules does address verification
>via SMTP. Since smtp
I believe that I've seen this discussed previously, so maybe there's
some interest in it. I wrote a threaded mail filtering framework a
while ago, and one of the modules does address verification via SMTP.
Since smtplib.SMTP uses blocking IO, it can block the whole
interpreter. Sometimes the
