Rebuild worker pool around channel-driven scheduling

README.md

@@ -16,22 +16,24 @@ if err := pool.Submit(func() { doWork() }); err != nil {
 ```
 
 The pool creates the minimum workers immediately and grows on demand up to the
-maximum. Its task queue has a fixed capacity of `maxWorkers/2`; once all workers
-and queue slots are occupied, `Submit` waits for room. `Close` stops new
-submissions and waits for accepted tasks to finish. A successful `Submit` means
-the task was accepted; it does not mean the task has started or finished. With
-`maxWorkers == 1`, the queue has zero capacity and submissions wait for a worker.
+maximum. A channel-driven scheduler owns worker lifecycle and a FIFO task queue
+with fixed capacity `maxWorkers/2`; once all workers and queue slots are
+occupied, `Submit` waits for room. With `maxWorkers == 1`, the queue has zero
+capacity and submissions wait for a worker. A successful `Submit` means the
+scheduler accepted the task; it does not mean the task has started or finished.
+`Close` stops new submissions and waits for accepted tasks to finish.
 
 After a task finishes, a worker exits immediately only when `total > min` and
 the number of *other* idle workers is greater than `min/2`. There is no idle
-timeout. A task panic is logged and that worker continues with later tasks.
+timeout.
 
 Only `Close` shuts down the pool. A task panic is logged and the same worker
-continues. A worker scheduling panic or `runtime.Goexit` terminates that
-worker; the pool starts a replacement as needed, and accepted queued tasks
-remain available even while `Close` is draining. The task that panicked or
-called `runtime.Goexit` is not retried. Call `Close` from outside pool tasks so
-it does not wait for itself.
+continues with later tasks. A worker scheduling panic is logged and terminates
+that worker; if accepted work is queued, a replacement worker takes the oldest
+task. A panicking task is not retried. An exceptional worker exit with no
+queued work does not proactively restore the minimum count; later submissions
+can grow the pool again. During `Close`, queued accepted work is still drained.
+Call `Close` from outside pool tasks so it does not wait for itself.
 
 A task may submit another task to the same pool. If all workers block submitting
 to a full queue, the caller must resolve that deadlock in its task logic.