In the browser Worker API, what is the difference between calling `worker.terminate()` from the page and calling `self.close()` inside the worker, and what happens to work that is still in flight?

## Two ends of the same rope A dedicated worker's lifetime is owned jointly. The page holds a `Worker` object and can pull the plug; the worker holds its own global and can retire itself. There are correspondingly two shutdown APIs, and they are not interchangeable. ## terminate() — the external kill ```js const worker = new Worker(new URL('./search.js', import.meta.url), { type: 'module' }); // ...later, the user navigated away from the search panel worker.terminate(); ``` `terminate()` aborts the worker immediately. Concretely: - The currently running script stops wherever the browser can stop it. It does not run to the end of the statement list. - No `finally` blocks, no `unload`-style hook, no destructor. Anything you were going to flush is lost. - Queued messages in both directions are dropped. A result the worker had already posted but the page had not yet dispatched will not arrive. - The page receives **no event**. `terminate()` returns `undefined` synchronously and there is no `terminated` callback to observe. - The `Worker` object is now inert. Calling `postMessage()` on it does nothing useful, and there is no restart — construct a new `Worker` instead. That abruptness is the point: it is the tool for a worker that has wedged itself in an infinite loop, or for cancelling expensive work whose result nobody wants any more. Because a worker cannot be interrupted cooperatively while it is inside a long synchronous computation — it is not checking a flag, it is busy — `terminate()` is often the *only* way to cancel that computation. ## self.close() — the cooperative retirement ```js // worker.js self.onmessage = (event) => { const result = expensiveTransform(event.data); self.postMessage(result); // deliver first self.close(); // then retire console.log('this line still runs'); }; ``` `close()` sets the worker's closing flag. From that moment the worker's event loop discards its queued tasks and refuses new ones: pending `setTimeout` callbacks will not fire, further `message` events are not dispatched, in-flight `fetch` responses are not delivered. What it does *not* do is stop the current turn. The statements after `close()` in the same function still execute — it behaves nothing like `return` or `process.exit`. That is useful, because it means the natural ordering "post the result, then close" works: the message has already been queued to the page and is unaffected by the worker's own shutdown. A worker that closes itself cannot be revived. The page's `Worker` object stays around but is dead; there is no event telling the page that it happened, so if the page needs to know it must be told by an ordinary message just before the close. ## Leaks: the case nobody calls either The most common real-world bug is neither API — it is forgetting both. A worker is not garbage collected merely because your code has stopped using it: as long as the page holds a reference and the worker has not closed, the thread and its heap stay alive. Patterns that spawn a worker per interaction and never terminate it accumulate threads, each with its own JS heap, until the tab is noticeably fat and the machine is oversubscribed. The two safe shapes are a **long-lived worker** you create once and keep for the feature's lifetime, and a **short-lived worker** that is explicitly torn down on the same lifecycle event that created it: ```js let worker = null; function openPanel() { worker = new Worker(new URL('./index.js', import.meta.url), { type: 'module' }); } function closePanel() { worker?.terminate(); worker = null; } ``` Dedicated workers are tied to their owning document, so a full page navigation tears them down for you — but a single-page app that never navigates gets no such rescue. ## Choosing between them Use `close()` when the worker is the one that knows it is finished: a one-shot job worker, or a worker that has hit an unrecoverable internal error and wants to stop cleanly after reporting it. Use `terminate()` when the *page* is the one that knows: the feature was closed, the user cancelled, a newer request superseded the old one, or a watchdog decided the worker is stuck. If you find yourself wanting `terminate()` mid-computation regularly, that is a hint the job should be split so the worker can also notice cancellation between chunks — but keep `terminate()` as the backstop, because a genuinely runaway loop will never notice anything.