ashleyk_: one thing to check is whether the code you're calling in the thread has some kind of built-in timeout support. not all libraries do, but some do.
glyph reviewed <https://tm.tl/#9288> - Don't raise AlreadyCalled in Request.getSession when the previous session has expired. (assigned to adiroiban)
glyph reviewed <https://tm.tl/#9463> - _sslverify uses md5 to generate unique session identifiers (assigned to mstojcevich)
glyph reviewed <https://tm.tl/#9482> - t.w.h.HTTPFactory docstring should mention reactor is used for timeouts (assigned to twm)
lovely, threads getting stuck with 'established' and 'closed_wait' connections that never go away, not a twisted thing though
if these seemingly 'impossible' things are going to happen, then i have no choice but to use some subprocess method so i can kill it when the tcp stack / kernel screws up
when i ctrl+c'd the client process with the stuck tcp ports, it exited immediately. so. threads were ready to exit, just never did...
doesnt make much sense to me how threads can just forget to exit and leave their tcp ports in some eternal CLOSE_WAIT or ESTABLISHED
maybe it was a twisted thing
at least my limiting code kept everything from running out of FDs, so i could detect this stuck connection/thread issue probably being the main issue