[Twisted-Python] Re: CLOSE_WAIT (debian)

[glyph at divmod.com]

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?