Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't hold a reference to the last job in the thread cache #1639

Merged
merged 3 commits into from
Jun 23, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions newsfragments/1638.fix.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
The thread cache didn't release its reference to the previous job.
2 changes: 2 additions & 0 deletions trio/_core/_thread_cache.py
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,8 @@ def _work(self):
# instead of spawning a new thread.
self._thread_cache._idle_workers[self] = None
deliver(result)
del fn
del deliver
else:
# Timeout acquiring lock, so we can probably exit. But,
# there's a race condition: we might be assigned a job *just*
Expand Down
25 changes: 24 additions & 1 deletion trio/_core/tests/test_thread_cache.py
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
import time
import sys

from .tutil import slow
from .tutil import slow, gc_collect_harder
from .. import _thread_cache
from .._thread_cache import start_thread_soon, ThreadCache

Expand All @@ -25,6 +25,29 @@ def deliver(outcome):
outcome.unwrap()


def test_thread_cache_deref():
res = [False]

class del_me:
def __call__(self):
return 42

def __del__(self):
res[0] = True
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this is the instance's destructor, where my original report was on the class destructor

but I see that the bug indeed affects both of these. (I suppose that not destroying the instance is enough to keep a reference to the class?)

does this variant of the test fail before the patch?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this variant of the test fail before the patch?

I see it does 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't easily reproduce the problem using a class destructor, so I opted for a minimal test that shows the reference to be gone / some destructor to be called.


q = Queue()

def deliver(outcome):
q.put(outcome)

start_thread_soon(del_me(), deliver)
outcome = q.get()
assert outcome.unwrap() == 42

gc_collect_harder()
assert res[0]


@slow
def test_spawning_new_thread_from_deliver_reuses_starting_thread():
# We know that no-one else is using the thread cache, so if we keep
Expand Down