Allow postMessage-ing AbortSignal

[Jamesernator]

Currently communicating to a worker that work should be aborted is somewhat annoying. This is especially true for work that may be run in a synchronous loop as one can not simply send forward a MessageChannel that signals aborting, but rather you need to send a SharedArrayBuffer that can be synchronously read.

I'd like to propose the ability to .postMessage an AbortSignal so that we can communicate aborting to workers in a consistent way to aborting on the main thread. Ideally this would support the synchronous case as well (e.g. calling controller.abort() from the original thread would synchronously update signal.aborted in the other thread so that compute loops can simply do if (signal.aborted) { /* terminate work */ }).

If there's interest, I would be willing to create a PR for this.

[annevk]

Wouldn't that mean that signal.aborted !== signal.aborted sometimes? I don't think we want that.

[Jamesernator]

Wouldn't that mean that signal.aborted !== signal.aborted sometimes?

Yes. Although once true, always true.

I don't think we want that.

Is there any particular reason? Web APIs that accept AbortSignal could already observe such behaviour if they wanted to, this would simply allow work in other userland threads (workers) to be able to behave similarly. The spec already explictly allows this behaviour for such Web APIs (see note below remove abort signal).

And from what I've found, doing a macrotask to allow any asynchronous notifications to come through actually kills performance quite heavily in some cases (compared to Atomics.load()). Although this concern could be separately addressed by an API that allows fast checking for any pending worker messages (e.g. if (self.areMessagesPending) { await self.flushMessages(); }).

[domenic]

Yeah, breaking signal.aborted !== signal.aborted is not something we do on the web platform. It violates the run to completion semi-invariant, which can currently only be violated by the very special object SharedArrayBuffer.

[domenic]

Web APIs that accept AbortSignal could already observe such behaviour if they wanted to

That isn't true? aborted can only be observed on the main thread, and if author JavaScript is running on the main thread, then web API browser code cannot be.

[Jamesernator]

That isn't true? aborted can only be observed on the main thread, and if author JavaScript is running on the main thread, then web API browser code cannot be.

I mean they don't necessarily go via .aborted, but there's this note that implies that they can observe it basically anytime they need:

The abort algorithms enable APIs with complex requirements to react in a reasonable way to abort(). For example, a given API’s aborted flag might need to be propagated to a cross-thread environment, such as a service worker.

It violates the run to completion semi-invariant, which can currently only be violated by the very special object SharedArrayBuffer.

Yes this is what I'm currently using for aborting in compute loops in workers, but it is a bit annoying not to be able to use the same API on one side that is used throughout the rest of the code.

Also my proposal doesn't actually violate run to completion, as it doesn't allow any additional JS code to run at the same time, in this regard is isn't significantly different to Date.now() !== Date.now() or Math.random() !== Math.random() or the recently shipped in Chrome navigator.scheduling.isInputPending() !== navigator.scheduling.isInputPending().

[Jamesernator]

Just to clarify how I'd imagine this working, if AbortSignal were implemented in js I would imagine doing something like this.

I've added an explicit synchronizeAborted method to this example, rather than having .aborted do this implictly (previously I was thinking .aborted getter would trigger .synchronizationSteps(), but it adds work for code paths that don't need it).

// Structured serialize steps
function serializeAbortSignal(abortSignal) {
  if (abortSignal.aborted) {
    return { type: "AbortSignal", aborted: true };
  } else {
    const messageChannel = new MessageChannel();
    abortSignal.addEventListener("abort", () => {
      // Update so aborted can be observed synchronously
      Atomics.store(sharedAbort, 0, 1));
      // And send it in case it's listening asynchronously
      messageChannel.port1.postMessage("aborted");
      messageChannel.port1.close();
    });
    const sharedAborted = new Uint8Array(new SharedArrayBuffer(1));
    return { 
      type: "AbortSignal", 
      aborted: false, 
      abortPort: messageChannel.port2,
      sharedAborted,
    };
  }
}

// Structured deserialize steps
function deserializeAbortSignal(serializedAbortSignal) {
  const abortSignal = new AbortSignal();
  
  if (serializedAbortSignal.aborted) {
    abortSignal.[[aborted]] = true;
    return abortSignal;
  }
  
  const { abortPort, sharedAborted } = serializedAbortSignal;
  // When a request to synchronize abort state with the main thread
  // happens we need to potentially fire "abort", and return 
  abortSignal.[[synchronizeSteps]] = () => {
    if (Atomics.load(sharedAborted, 0)) { // If aborted is set
      // Set the aborted flag synchronously
      abortSignal.[[aborted]] = true;
      // Fire the abort event and run any handlers synchronously
      abortSignal.dispatchEvent(new Event("abort"));
      abortPort.close();
    }
  };
  
  // Abort asynchronously if synchronizeAbort is not used
  abortPort.addEventListener("message", () => {
    if (abortSignal.[[aborted]]) return;
    abortSignal.[[aborted]] = true;
    abortSignal.dispatchEvent(new Event("abort"));
    abortPort.close();
  });
  
  return abortSignal;
}

class AbortSignal extends EventTarget {
  [[aborted]] = false;
  [[synchronizeSteps]] = () => void;

  get aborted() {
    return this.[[aborted]];
  }
  
  // This asks the abort signal to synchronize with the other thread
  // by default the synchronize steps are to do nothing, this is the
  // case today and would remain the case when the abort signal does
  // not come from another thread
  synchronizeAborted() {
    if (this.[[aborted]]) {
      return true;
    }
    this.[[synchronizeSteps]]();
    return this.[[aborted]];
  }
}

// inside a worker

self.addEventListener("message", (evt) => {
  const { abortSignal } = evt.data;
  while (true) {
    // Synchronize abortSignal with the main thread and return true if aborted
    if (abortSignal.synchronizeAborted()) { 
      break;
    }
    // ...heavy compute...
  }
});

[jasnell]

Just to offer a different perspective on this... in Node.js (which is, of course, a different environment than browsers) we have more of a notion of objects that can be shared across workers -- much like SharedArrayBuffer but for other host objects we provide. In that environment, we actually could actually have two different AbortSignal objects (one in each thread) sharing the same underlying backend such that signal.aborted === signal.aborted. (It's not implemented this way today... but we could).

[Jamesernator]

With the new abortSignal.reason synchronous observation doesn't really make sense anymore as one also needs to send the reason across the thread which is considerably less simple than the setting of a boolean cross-thread, however the asynchronous part of the API still would make sense.

For this we could have a design more like:

AbortSignal serialization steps given _abortSignal_ and _serialized_:

1. If _abortSignal_ is **aborted**.
  a. Set _serialized_.[[AbortReason]] to _abortSignal_'s **abort reason**.
  b. Set _serialized_.[[MessagePort]] to **undefined**.
2. Else.
  a. Let _port1_ be a new MessagePort in the current realm.
  b. Let _port2_ be a new MessagePort in the current realm.
  c. Entangle _port1_ and _port2_.
  d. Set _serialized_.[[AbortReason]] to **undefined**.
  e. Set _serialized_.[[MessagePort]] to the **sub-serialization** of **port2**.
  f. Add the following **abort algorithm** to _abortSignal_:
    a. Post a message consisting of _abortSignal_'s **abort reason** to _port1_.
    b. Disentangle _port1_.
    
AbortSignal deserialization steps given _dataHolder_ and _value_:

1. If _dataHolder_.[[AbortReason]] is not **undefined**:
  a. Abort _value_ with _dataHolder_.[[AbortReason]].
2. Else.
  a. Assert _serialized_.[[MessagePort]] is a MessagePort.
  b. Add a handler for _serialized_.[[MessagePort]]'s "message" event with the following steps:
    i. **abort** _value_ with the *data* of the message.
    ii. Disentangle _serialized_.[[MessagePort]]

[annevk]

That seems reasonable to me and is compatible with what we are planning to do for Fetch (see whatwg/fetch#1343). (The current plan there is to serialize/deserialize abort reason and recreate the AbortSignal as we already have a channel with the service worker, but it's not distinguishable from the above I think.)

[jasnell]

There is a challenge here since given that the structured clone algorithm doesn't handle custom Error objects well without losing data. Some platforms that might not be able to handle DOMException as a host object, for instance, might not be able to deserialize it as a DOMException on the receiving end. And if I set reason to an Error subclass (e.g. class FooError extends Error), it will come across as just an Error on the other side. That's not to say we should block making AbortSignal transferable, only that we need to acknowledge the limitations and lack of fidelity. (I believe we already have the same issue with communicating errors in the streams impl so it's not a new issue)

[Jamesernator]

That seems reasonable to me and is compatible with what we are planning to do for Fetch (see whatwg/fetch#1343). (The current plan there is to serialize/deserialize abort reason and recreate the AbortSignal as we already have a channel with the service worker, but it's not distinguishable from the above I think.)

I'm happy to make a PR if you want.

There is a challenge here since given that the structured clone algorithm doesn't handle custom Error objects well without losing data. Some platforms that might not be able to handle DOMException as a host object, for instance, might not be able to deserialize it as a DOMException on the receiving end.

This is part of the wider issue of not having any userland way of having custom structured serialized things. How do existing structured clonables/transferables like MessagePort work in Node?

Nowadays it might be more viable to have userland structured cloning by just pointing to an ES module for deserialization. With module blocks the ergonomics of it could even be rather nice as you could just return a module block from some hypothetical serialize method. This is just an idea on my part though and is well beyond the scope of this issue though.