Clear worker thread cache after forking#3200
Conversation
|
Maybe there should be a way to tell Trio "hey I don't want the worker threads anymore, please kill them!", especially in light of the new deprecation warning (ATM the way to do that is to do That's not what this PR does! Counterpoint: what if a thread is currently doing work (no guarantees even outside of a |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3200 +/- ##
===============================================
Coverage 100.00000% 100.00000%
===============================================
Files 124 124
Lines 18792 18818 +26
Branches 1268 1270 +2
===============================================
+ Hits 18792 18818 +26
|
|
coverage fail appears to be coveragepy/coveragepy#310 |
CoolCat467
left a comment
There was a problem hiding this comment.
Not sure if I completely understand the test for this, but the actual functionality changes look fine.
94d51b2 to
04845c8
Compare
jakkdl
left a comment
There was a problem hiding this comment.
unclear if the coverage stuff is worth it, though I guess we do get confirmation that the else branch is executed even though the coverage itself is only on the coverage stuff.
very good comments, would have been a pain to figure out those details otherwise :)
|
The coverage stuff definitely isn't worth it for the test coverage, but doing this stop/save thing also covers the callback from register_at_fork. Otherwise that doesn't get any coverage. |
Fixes #2764
While we don't provide any sort of guarantees and I think it's tempting to give up on this:
As long as people aren't initializing their own thread caches, this should be fine.