Scheduler Lifecycle
Last updated
This page shows how each scheduler operation behaves before
Start and while the event loop is running.Operations by State
| Operation | Not started | Running |
|---|---|---|
Add | Appended to the heap directly | Sent to the event loop via the add channel |
Remove | Disabled and removed from the heap | Removed via the remove channel |
RemoveAll | Disables every task | Clears the heap via the removeAll channel |
Start | Starts the worker pool and event loop | No-op |
Stop | Returns an immediately cancelled context | Stops the loop, waits for workers, returns a context cancelled after in-flight tasks finish |
Restarting After Stop
Start after Stop restarts the event loop, so tasks without dependencies fire again. The dependency workers do not come back: Stop closes the workers' stop channel and Start reuses it, so each new worker exits immediately. Dependent tasks are then queued on trigger but never evaluated, and once the 1024-slot wait queue is full the event loop blocks. A second Stop after such a restart closes the same channel again and panics with close of closed channel. Create a new scheduler with core.New instead of restarting one that has dependent tasks.See Scheduler API for
New, Start, and Stop signatures.