Cancel in-flight worker jobs

[kmatzen]

Follow-up to #50, which fixed response routing in WorkerBridge but deliberately left cancellation out of scope.

Problem

The worker processes self.onmessage synchronously to completion (src/worker/sdfWorker.ts:165). There is no way to drop queued or in-progress work. Every request now settles, but a 256³ export still blocks every evaluate queued behind it — the viewport stalls for the duration of an export.

evalSeq only discards results. The work itself always runs. Editing the tree ten times during an export queues ten full evaluations that will all execute after it finishes, and nine of their results get thrown away.

Options

Cancel message + cooperative checks. Keep a set of cancelled rids in the worker; check it inside the recursion in evaluateCPUWithProgress (sdfWorker.ts:93) and in the simplifyMesh progress callback. Cancels queued work cheaply and interrupts in-progress work at the next check. Requires threading the check through the hot loops, and granularity is bounded by how often you check.

Terminate and respawn. worker.terminate() kills in-progress work immediately, then construct a fresh Worker. Simple and total, but pays worker startup on every cancel and drops every other in-flight request — so the bridge would have to reject them all, and the ready handshake has to be re-awaited.

Second worker for exports. Sidesteps head-of-line blocking entirely rather than cancelling: evaluates never queue behind an export. Doesn't help with rapid successive evaluates superseding each other, and doubles worker memory.

These compose — a dedicated export worker plus cooperative cancellation for evaluates may be the right end state.

Notes

The correlation-id map in WorkerBridge already gives cancellation a place to hook: a cancelled request needs to be settled (rejected, or resolved with null) and removed from pending, preserving the HandlerAgreesWithSettled invariant documented in specs/README.md.

Worth extending specs/WorkerBridgeFixed.tla once an approach is chosen. The interesting property is not just "cancelled requests settle" but that a cancel racing with an in-flight completion does not settle the request twice or strand it — which is exactly the shape of bug the original spec caught.

[kmatzen]

Scope update: option 3 shipped in #60, so the headline symptom is already gone

The "Problem" section here leads with head-of-line blocking — "a 256³ export still blocks every evaluate queued behind it — the viewport stalls for the duration of an export". That is the second worker for exports option, and it landed in #60. WorkerBridge now runs an evalChannel and an exportChannel, and workerBridge.ts documents the split in place:

This is not cancellation: a superseded evaluate still runs to completion, it just no longer waits on an export. See #51.

e2e/app.spec.ts covers it (Modeler: Worker concurrency › viewport keeps evaluating while an export runs).

So what remains for this issue is narrower than the opening describes: superseded evaluates still execute. Editing the tree ten times still queues ten full evaluations on the eval channel, and evalSeq only discards nine sets of results after the work has already been done. That's wasted CPU and latency on the newest edit, but it no longer stalls the viewport behind an export.

Worth editing the issue body so the remaining scope isn't mistaken for the original one — otherwise it reads as though the viewport still freezes during exports, which it doesn't.

On the remaining work

Of the two cancellation options, cancel message + cooperative checks is the one that fits what's left. terminate()/respawn is a poor trade here specifically because the export channel already exists: the thing you want to cancel is a cheap, frequent evaluate, and paying worker startup plus rejecting every co-resident request to drop one superseded evaluate costs more than the work it saves.

The note about extending specs/WorkerBridgeFixed.tla still stands, and is the valuable part. The interesting property is the race — a cancel arriving as an in-flight completion is being routed must not settle the request twice or strand it — which is the shape the original spec caught. Cancellation adds a second way for a pending entry to be removed, so HandlerAgreesWithSettled is exactly the invariant at risk.