Repository navigation
Conversation
rr0gi
approved these changes
Sep 29, 2026
rr0gi
left a comment
rr0gi
left a comment
Contributor
There was a problem hiding this comment.
i think better add counters to do_stop, this way can see when workers are exiting slowly / not uniformly. You decide
Count workers in the "parallel.forks" Var family, per event: spawned, succeeded (exit status 0), failed (non-zero exit status), signaled (killed by a signal), vanished (lost without a status, e.g. mid-task in the pool) and force_killed (SIGKILLed for not stopping in time). Exits are counted as workers are reaped, so slow or uneven stops show up while they happen. Counters are process-wide as in Httpev: several run_forks calls are not told apart. They are reset in forked children, which would otherwise report the parent's counts frozen at fork time. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Niols
force-pushed
the
parallel-fork-counters
branch
from
October 14, 2026 11:51
a3da706 to
240a85f
Compare
Author
|
Updated the PR with most of the work happening in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a
parallel.forksVarfamily to gain observability on workers forked byParallel.run_forks. Counted per event:spawned— worker was forkedsucceeded— exited with return code 0failed— exited with non-zero return codesignaled— stopped from a signal, whether it is aSIGINTorSIGTERMcoming from the parent, or coming from anywhere else, or stuff likeSIGABRT, etc. I don't think we should do any special treatment of signals at the level of Devkit because their semantics depends a lot on the final program and what workers do with signals.vanished— crashed, disappeared, etc.force_killed— worker did not stop in time and was SIGKILL'edWe already have startup and termination event sent by the processes themselves, which I believe duplicates the work of
spawnedandexited, so let me know if I should clean those up. Workers that getforce_killed, thatvanished, or that died becausesignaledpresumably don't get to write this termination event.I decided to imitate
httpev.forksin that the counters are process-wide and severalrun_forksin the same process cannot be told apart. I also haven't allowed passing a~attrsor something to customize the vars in each call. Let me know if you would want something different.See https://ahrefs.slack.com/archives/C01NT4U32JD/p1790263319380559