Repository navigation
Conversation
Mixed activityActivity patterns show a mix of organic and automated signals. Evidence
Last 5 PRs:
This is an automated analysis by AgentScan |
shrink() subtracted the shutdowns that earlier calls had queued from the amount it was asked for, before it removed the threads that had already exited. So a call made before an earlier call's threads were reaped was mostly ignored: four shrink(20) calls in a row retired 20 of 90 threads, and 40 when made a second apart. The idle property already leaves those threads out, so a caller that sizes the amount from it had them subtracted twice. The threads above the minimum were also counted with those already shutting down: shrink(40), then shrink(80), on 50 threads with a minimum of 10 retired all 50, and left 30 requests queued. shrink() now asks up to that many more threads to shut down, among those above the minimum that are not shutting down yet. stop() used to queue a request for every thread it listed, dead ones included, so the next start() lost its new threads to the requests left over and waited for them forever. It now queues one for each live thread that shrink() has not asked already, and forgets the pending shutdowns. Generated-By: Anthropic Claude Opus 5.5 Signed-off-by: Adam Harwell <flux.adam@gmail.com>
d6337a6 to
1df9482
Compare
pyba-chronographer
Bot
added
the
bot:chronographer:provided
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #859 +/- ##
==========================================
+ Coverage 78.20% 78.63% +0.43%
==========================================
Files 41 41
Lines 4791 4836 +45
Branches 548 550 +2
==========================================
+ Hits 3747 3803 +56
+ Misses 904 893 -11
Partials 140 140 |
|
Hey, just dropping a quick note here since I just posted this and #858 with Claude, as I want to be clear that while Claude wrote most/all of the code here, there is a real human behind these driving and doing first-pass reviews, and these are bugs I've been tracking internally for quite a while. We use cheroot to serve parts of an in-development RPC system in OpenStack's oslo.messaging project, and we trip over this periodically depending on deployment style. I will be tracking these and am happy to make adjustments based on feedback, or drop these PRs if there's a better approach from someone who knows the codebase better than I (and AI) do. Thanks! |
|
I'm pretty sure the failed test is not related to this, maybe someone can re-run it? |
This branch has not been deployed
1 participant
What kind of change does this PR introduce?
What do these changes do?
shrink()subtracted the shutdowns that earlier calls had queued from the amount it was asked for, before it removed the threads that had already exited. So a call made before an earlier call's threads were reaped was mostly ignored.idlealready leaves those threads out, so a caller that sizes the amount from it, as dynpool does, had them subtracted twice. The threads above the minimum were also counted together with those already shutting down, so the pool could drop belowmin.stop()queued a shutdown request for every thread it listed, including those thatshrink()had already retired but that were not reaped yet, and never reset_pending_shutdowns. The requests left over then stopped the threads of the nextstart(), and itsgrow()waited for them forever.HTTPServer.prepare()on a stopped server starts the pool again, as CherryPy does when its bus restarts.shrink()now asks up to that many more threads to shut down, among those above the minimum that are not shutting down yet.stop()queues one request for each live thread thatshrink()has not asked already, and forgets the pending shutdowns once the threads are joined.shrink(20)on 90 threads,min10shrink(40), thenshrink(80), on 50 threads,min10start()aftershrink()andstop()The three new tests fail without the change; the restart test fails by a timeout rather than hanging the run.
Are there changes in behavior for the user?
shrink(amount)now retires up toamountmore threads, counting those already shutting down as gone, asidledoes, and never belowmin. #204 settled thatamountcounts the shutdowns already scheduled. That still holds for a caller that sizes it fromidle, but one that subtracts pending shutdowns itself would now shrink more. Nothing in cheroot or CherryPy callsshrink().Is it a substantial burden for the maintainers to support this?
No. It changes how two methods count, in a few lines, and the new tests cover all three cases.
Related issue number
Fixes #861. A related statistics retention problem, #860, is fixed in #858.
Checklist
Tip
New to open source contributions? Making a lovely PR is a great read.
and description in grammatically correct, complete sentences
docs/) and inline docstrings reflect the changes(see good commit messages)
(can be done once the PR number is known; alternatively, you can
use a related issue number if one exists)
code of conduct
This change, its tests and this description were written by an AI agent (Anthropic Claude Opus 5.5) on behalf of Adam Harwell (@rm-you). The tests and the pre-commit checks were run locally with Python 3.11;
mypy-stubtestwas skipped, as Python 3.12 is not installed there.🤖 Generated with Claude Code