Author martin.panter
Recipients Wei Li, martin.panter, maru-n, vstinner
Date 2019-06-17.01:47:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1560736065.96.0.0771991843935.issue37193@roundup.psfhosted.org>
In-reply-to
Content
Looking at the code, this would be caused by Issue 31233. I expect 3.7+ is affected. 3.6 has similar code, but the leaking looks to be disabled by default. 2.7 doesn't collect a "_threads" list at all.

Looks like Victor was aware of the leak when he changed the code: <https://bugs.python.org/issue31233#msg304619>, but maybe he pushed the code and then forgot about the problem.

A possible problem with Norihiro's solution is modifying the "_threads" list from multiple threads without any synchronization. (Not sure if that is a problem, or is it guaranteed to be okay due to GIL etc?) Also, since the thread is removing itself from the list, it will still run a short while after the removal, so there is a window when the "server_close" method will not wait for that thread. Might also defeat the "dangling thread" accounting that I believe was Victor's motivation for his change.

Wei's proposal is to check for cleaning up when a new request is handled. That relies on a new request coming in to free up memory. Perhaps we could use similar strategy to the Forking mixin, which I believe cleans up expired children periodically, without relying on a new request.
History
Date User Action Args
2019-06-17 01:47:45martin.pantersetrecipients: + martin.panter, vstinner, maru-n, Wei Li
2019-06-17 01:47:45martin.pantersetmessageid: <1560736065.96.0.0771991843935.issue37193@roundup.psfhosted.org>
2019-06-17 01:47:45martin.panterlinkissue37193 messages
2019-06-17 01:47:45martin.pantercreate