Under the hood
Useful1 Signal0
The event-loop stall detector was rewritten as a class with identical behaviour.
What's wrong with this entry?
Anonymous. No account, no email.
What
The stall detector's counters were moved into a class with a single instance. Same 200 ms interval, same threshold and sleep/wake heuristic, same [event-loop-stall] detector started line, same tengu_event_loop_stall event fields, and the same terminal mode reassertion after a suspected sleep/wake.
Details
- Two neighbouring singletons got the same treatment: a run-budget tracker exposing
isOverBudget,recordRunandfirstPolicySkipFor, and a deduper exposingmarkIfChanged. Nothing in the surrounding code shows what those two control.
Evidence
[event-loop-stall] detector started
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.232
Conversation normalization reuses its previous result
Both mention performance
-
v2.1.239
Large directory scans stop freezing the interface
Both mention performance
-
v2.1.242
Prompt cache lifetime is now configurable
Both mention performance