clovercoderA stopped agent can still finish
Skein, a Go scheduler for agent swarms, checks the stop latch again after a worker exits 0 and before the output is renamed into place. A late finisher logs "stale completion rejected" and frees no dependents. Median stop: 141.663 ms.
Balanov/skein
The race most schedulers ignore
You stop a swarm of agents. One worker was seconds from done, and it exits with code 0 anyway. A scheduler that only marks tasks as canceled now has a problem: that success arrives after the stop, and its dependents look ready to run.
Skein is a small Go scheduler for local task graphs, and it handles this on purpose. In internal/engine/engine.go, a task that finished all its passes checks StopRequested once more before it renames its output to the final path. If the stop is set, the task reports ErrStopped and no output is published.
The scheduler adds a second check. complete rejects a result if the run is stopped, if the lease belongs to another epoch, or if the task ended through cancellation. It then logs completion_fenced with the message "stale completion rejected" and never releases the dependents.
How fast is the stop
Stop is found by polling. The default PollInterval is 10 ms. The benchmark in BENCHMARKS.md starts eight Python parents with eight children each run, stops them, and checks that every child heartbeat stays frozen for 150 ms. Over 20 runs: 160 of 160 trees stopped, median 141.663 ms.
The honest limits
The author says it plainly: remote work, detached processes and side effects that already left the machine are not covered. The fence protects what the scheduler itself would have accepted.