Workers: the Worker constructor, the two façades and the connection lifecycle

[lahma]

Step 2–3 of the Web Workers plan (#3167 §14): new Worker(specifier, { type: 'module' }) now runs a real
worker — a second Engine the host's WorkerProvider built, pumped on whichever thread the host chose,
entangled with its parent by a MessagePort pair neither side ever sees.

The constructor (issue §5, ten steps in order): WebIDL first and in the dictionary's lexicographic
member order (credentials validated as RequestCredentials then ignored; 'classic' — the spec's own
default — refused with a TypeError whose message names the fix; an unknown type is the enum-conversion
TypeError); the per-engine MaxWorkers backstop as a QuotaExceededError with quota/requested; the
termination source minted before the provider is called; null from the provider a synchronous
SecurityError, a throw propagated unchanged; then validation of the returned engine —
InvalidOperationException naming the fix for the parent-engine mistake, missing Messaging, an engine
already running a worker, and an engine that does not observe request.TerminationToken (the
deaf-but-running worker becomes a construction-time error). Steps 6–10 run under EnterHostCall on the
worker engine, so a pre-warmed engine another thread is already pumping is refused with the engine's own
admission error instead of being corrupted; ownership is released before OnWorkerStarted, and the
connection is registered before the host is told to pump.

Three messaging primitives carry the façades, and one is a deliberate shipped-behavior change:

• JsMessagePort.RetargetTo — the event-creating sibling of Web streams: transfer a ReadableStream, a WritableStream or a TransformStream #3215's InternalMessageHandler: the hidden
  ports dispatch their message events at the Worker object and at the worker's global scope (HTML's
  "immediately retargeted"), with event.target answering what a browser answers. Both façades enable
  eagerly — the onmessage-implies-start() rule is scoped to the MessagePort interface, and on a
  worker addEventListener('message', …) alone must receive.
• A draining endpoint state that is deliberately not Closed: a worker's close() leaves the
  parent-side queue deliverable-but-unjoinable (HTML's close a worker has no counterpart to terminate's
  empty-the-queue step), so postMessage(result); close() still delivers — while IsChannelExhausted
  stays truthful for a transferred stream whose own close message is still queued, which is exactly the
  case that predicate exists for.
• DrainOne now arms the next delivery after the dispatch, in a finally. Arming first put the next
  drain job ahead of the reactions the listener queued, delivering two messages back to back — the order is
  observable and is HTML's (a message is a task; everything it queued runs before the next message is
  looked at). This changes shipped MessagePort behavior and is pinned for a plain MessageChannel too.

The start job runs on the worker's own loop with the worker's generation — no part of the worker's
script ever runs on the parent's thread, pinned. It calls Modules.StartImport and attaches reactions:
fulfil enables the inner queue (messages posted before the module evaluated arrive buffered, in order);
reject ends the connection as StartupFailed with a CLR exception on WorkerConnection.Error — the
CLR exception behind the failure when there is one, otherwise a summary built from own data properties
only, so no getter runs during teardown and no worker-realm JsValue crosses a thread. The parent-side
error event is wave 3; the connection surface needs no sink at all.

terminate() and close() split exactly as the spec splits them (§6.1/§6.2): terminate closes both
endpoints immediately (still serializing afterwards, so DataCloneError still throws and transfers still
detach — pinned), cancels the token, reports Terminated; close() disentangles the worker's side now,
lets the current turn finish (the teardown is a job on the worker's own loop — which is also why it alone
does not cancel the token: the teardown runs on the pumping thread, which sees IsEnded on its next
iteration, and cancelling would make straggler jobs erupt from the host's pump after a clean close), and
drains-then-closes the parent side. MaxQueuedMessages is enforced per direction before serialization.

The worker global scope carries §8's table — postMessage (both overloads, transfer list verbatim, so a
MessagePort or a transferred stream rides back untouched), close, name, the onmessage/
onmessageerror/onerror/onunhandledrejection/onrejectionhandled attributes over the synthetic global
listener list (WinterTC §5.3's exact set), and importScripts present-and-throwing TypeError — the
spec's own step 1 for a module worker, the one place the family's absent-rather-than-throwing convention
loses to the standard prescribing the throw. No WorkerGlobalScope interface object. The wave-1 pin that
asserted no script surface at all is replaced by the three-way typeof Worker pin (flag and provider
together, and only together).

Tests: 36 mechanism pins + 6 PublicInterface + 2 MessagingTests (the drain-order change on a plain
channel), 27 mutations applied to shipped code with every named pin verified to fail, threading pins
rendezvousing on events (no wall-clock assertions), mechanism and PublicInterface worker suites run ×5
green. Full matrix green on both TFMs plus both JINT_HOST_CONTRACT_VERIFICATION=1 legs.

Wave 3 (the parent-side error channels with error: null and the notHandled relay, restore/dispose on
both sides) follows on the seams left for it: WorkerRegistry.Snapshot(), WebApiEngineState.OwningWorkerLink,
and the notes on WorkerLink.OnModuleFailed/WorkerPrototype.

Part of #3167.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PnghUC3EKrYa12xQ2LaYyd