ThreadCache workers leaking spawner's Context on py314+ free-threaded builds

[EmmanuelNiyonshuti]

fixes #3472

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00000%. Comparing base (976c11b) to head (eb8320f).

Additional details and impacted files

@@               Coverage Diff               @@
##                 main        #3473   +/-   ##
===============================================
  Coverage   100.00000%   100.00000%           
===============================================
  Files             128          128           
  Lines           19423        19439   +16     
  Branches         1317         1318    +1     
===============================================
+ Hits            19423        19439   +16     

Files with missing lines	Coverage Δ
src/trio/_core/_thread_cache.py	100.00000% <100.00000%> (ø)
src/trio/_tests/test_threads.py	100.00000% <100.00000%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[A5rocks]

Makes sense to me. Could you add a test? I guess just something to make sure that threads don't inherit context would work well enough.

[A5rocks]

Test could be simplified I think, but looks good to me.

[A5rocks]

IMO you should just check whether context gets carried over, no need for GC or whatever. Technically there could be a bug where we clear it in the frame before handing it to the user but store it elsewhere -- and you could test for that using weakref (to ensure it works on PyPy) -- but IMO not necessary.

[EmmanuelNiyonshuti]

Yeah, we could use weakref too. I leaned more towards how anyio did it.

[EmmanuelNiyonshuti]

Forgive these so many commits. Not sure if you squash commits when merging, but feel free to tidy them up if needed.

[CoolCat467]

Looks good as far as I can tell, though I agree test could probably be simplified.

[EmmanuelNiyonshuti]

@A5rocks what do you think about this approach? used weakref and just asserted that the object is dead.

[EmmanuelNiyonshuti]

PyPy failures are now irrelevant because we don't need gc.get_referrers anymore!

[EmmanuelNiyonshuti]

By the way, this was found while exercising anyio's test suite on the Python 3.14t free-threaded build. anyio has a regression test that checks for leaked references from its worker-thread pool, and running it against trio's backend surfaced this.

[A5rocks]

Thanks for this!

[trio-bot]

Hey @EmmanuelNiyonshuti, it looks like that was the first time we merged one of your PRs! Thanks so much! 🎉 🎂

If you want to keep contributing, we'd love to have you. So, I just sent you an invitation to join the python-trio organization on Github! If you accept, then here's what will happen:

• Github will automatically subscribe you to notifications on all our repositories. (But you can unsubscribe again if you don't want the spam.)

• You'll be able to help us manage issues (add labels, close them, etc.)

• You'll be able to review and merge other people's pull requests

• You'll get a [member] badge next to your name when participating in the Trio repos, and you'll have the option of adding your name to our member's page and putting our icon on your Github profile (details)

If you want to read more, here's the relevant section in our contributing guide.

Alternatively, you're free to decline or ignore the invitation. You'll still be able to contribute as much or as little as you like, and I won't hassle you about joining again. But if you ever change your mind, just let us know and we'll send another invitation. We'd love to have you, but more importantly we want you to do whatever's best for you.

If you have any questions, well... I am just a humble Python script, so I probably can't help. But please do post a comment here, or in our chat, or on our forum, whatever's easiest, and someone will help you out!