ef87f7e1b9
Research across ractor, tokio, Erlang/OTP BEAM, Linux CFS, and libuv revealed that tick_all drained the entire mailbox per actor per tick, allowing one hot actor to starve all others on the same worker. - Add `actor_message_budget` to RuntimeConfig (default: 64 msgs/actor/tick) - Modify tick_all to break after budget messages, yielding to next actor - budget=0 restores unlimited (backward compatible) behavior - 3 new fairness tests validating hot-cold actor scenarios - New fairness benchmark group (cold_latency_under_pressure, throughput_by_budget) - Fix RuntimeConfig struct literals across workspace crates Inspired by BEAM's 4000-reduction budget and tokio's 128-op cooperative budget. All 45 tests pass (42 original + 3 new). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
46 lines
No EOL
2 KiB
Markdown
46 lines
No EOL
2 KiB
Markdown
Plan:
|
|
You are to improve this codebase via:
|
|
- investigating similar codebases
|
|
- identifying and summarizing their design decisions when compared to swactor:
|
|
- runtime engine
|
|
- benchmarking
|
|
- testing
|
|
- overall performance
|
|
- etc.
|
|
- implementing improvements based on your anaylsis
|
|
|
|
Workflow:
|
|
- Read `CLAUDE/TASK.md` and `CLAUDE/notes/progress.md`
|
|
- Identify what stage you are on.
|
|
- Read and update yourself as necessary.
|
|
- Proceed to accomplishing the next task as written in `progress.md`
|
|
- For each attempt at any step, keep a record. If you reach attempt 3, step back, document, and try something else.
|
|
- When done, because attempt limit or task success:
|
|
- update `progress.md` with:
|
|
- Completed this session
|
|
- Next steps (specific, actionable)
|
|
- Open Questions
|
|
- Blockers
|
|
- make a commit
|
|
- compress your context and start the loop again
|
|
|
|
Style:
|
|
- Do not add to existing modules in the root swactor `src/` they should stay as they are. You may modify but not change module structure.
|
|
- Integration tests in `tests/`, benchmark code in `benches/` (cap benchmark execution time at 2 minutes max). You may modify these as you wish.
|
|
- Report all your changes to architecture with changes to the `docs/` items
|
|
- all notes you wish to keep across iterations shall go in the `CLAUDE/notes/` folder
|
|
|
|
Example loop (not restrictive, feel free to ignore if prudent):
|
|
- Pick a related codebase and a concept to execute (benchmarks, test coverage, engine performance under various scenarios)
|
|
- compare to swactor
|
|
- make analysis
|
|
- implement plan
|
|
- execute
|
|
- evaluate
|
|
- repeat
|
|
|
|
Before git commit:
|
|
- all `cargo test` passes, including feature gated material
|
|
- if a test fails, investigate do not ignore or delete
|
|
- You can combine tests but not skip code paths or delete them for active code
|
|
- if a fix takes > 3 attempts, log and move on |