[Twisted-Python] Re: CLOSE_WAIT (debian)
glyph at divmod.com
glyph at divmod.com
Thu Jun 5 04:04:08 MDT 2008
On 08:25 am, josef.robert.novak at gmail.com wrote:
>Hi, I've been digging around a bit more and it seems like it might be
>advisable for me to use the d.setTimeout(TIMEOUT) function for my
>deferToThread objects. I see from the docstrings that this is
>deprecated, and that I should rely on the timeout mechanism supplied
>by the API I'm using, however that doesn't seem to suggest an
>immediate solution. I dug up the following reference, but is it
>really such a bad idea to use d.setTimout(TIMEOUT)?
>http://twistedmatrix.com/pipermail/twisted-
>python/2004-April/007536.html
Yes. Double-yes for Deferreds returned from deferToThread.
So, first: if you have deferred a function to a thread, there is nothing
generic you can do to stop it. If that blocking function specifically
provides an API to stop it from other threads, then you can stop it.
Second, setTimeout was *never* a good idea. It's been deprecated for
long enough that it may be removed at any time; and probably will be,
soon. As it is implemented, you will pretty much always see a traceback
if the timeout actually fires. Unless the API is specifically written
to accommodate this style of timeouts (and none in Twisted are) the API
which is expecting to callback or errback a Deferred will instead
encounter an `AlreadyCalledError`, since the timeout has invoked it
already.
Your issue with CLOSE_WAIT sockets could be due to registering producers
which have no further data to produce. Does that sound like something
you, or starpy, might be doing?
More information about the Twisted-Python
mailing list