Consider adding AbortController.prototype.follow(signal)

[annevk]

See #920 (comment).

[jakearchibald]

The controller already has a strong reference to the signal, no? Via controller.signal. I guess that value could be overridden, but do we generally try to cater for cases like that?

[annevk]

Sorry, yeah, the controller keeps the signal alive, but not the other way around. I'll fix OP.

[jakearchibald]

Abort algorithms need to stick around while the controller is in reference and the signal is not aborted.

Abort events listeners need to stick around while the signal is in reference, or the controller is in reference and the signal is not aborted. But some of that seems redundant given the controller has a strong reference to the signal.

[annevk]

Oh yeah, I think the basic scenarios are fine already, indeed. My bad.

I guess the one thing that complicates things somewhat might be signals that follow other signals. Edit: would that be as simple as keeping it alive from the signal that it is following? At least as long as the aborted flag isn't set.

[MattiasBuelens]

I guess the one thing that complicates things somewhat might be signals that follow other signals. Edit: would that be as simple as keeping it alive from the signal that it is following? At least as long as the aborted flag isn't set.

Again, isn't that already the case by virtue of the followingSignal attaching abort steps to its parentSignal, and those steps necessarily keeping the followingSignal alive?

[MattiasBuelens]

On a slightly unrelated note: what is missing here is if the followingSignal is aborted separately (i.e. through its own abort controller, not as a result of the parentSignal becoming aborted). In that case, the followingSignal should remove the abort steps it had attached to its parentSignal, so that the parentSignal does not keep the followingSignal alive unnecessarily.

I don't think this shouldn't be too difficult to fix in the specification. I'll give it a try.

[annevk]

Hmm yeah. I'm not sure you can ever be a followingSignal with your own controller. Fetch uses this mechanism and always creates an "unowned" signal for this (as part of creating a new Request object).

[MattiasBuelens]

So either a specification calls "signal abort" on a signal, or it makes it "follow" another signal, but it can't ever do both on the same signal? I guess that makes sense, it's just not explicitly documented as a restriction. Not sure if we need to. 🤷

I've been using an AbortController/AbortSignal implementation in my own code, and I sometimes find it useful being able to do both on the same signal. For example, I'd have a "long-living" abort signal for the lifetime of an entire component, and then create "short-living" signals for tasks spawned by that component. These task signals can be aborted separately, but they also follow the long-living signal so all tasks are automatically aborted when the component is destroyed. But then again, this might be a very specific use case that isn't very useful for the whole of the web platform. 😅

Anyway, sorry for the sidetrack. So yeah, I think GC is already pretty okay for signals following other signals.

[jakearchibald]

But then again, this might be a very specific use case that isn't very useful for the whole of the web platform.

I had a use-case like this a couple of days ago fwiw. It was on squoosh.app, where there's a single controller that does overall things like decoding the input image, but then there are two other controllers for processing and encoding each side. Changing the encoding settings on one side only aborts the operations on that side, but dropping in a new image aborts main image decoding, and processing of both sides.

[annevk]

I guess we're really discussing a new issue now, but that's fine with me.

1. Following is not exposed, but we should perhaps document the limitation in case a specification tries to use it for something it doesn't work. I'd rather do that than make it work as it would be redundant at the moment.
2. Does following need to be exposed? It seems it should be doable to implement the scenarios you sketch in userland?

[MattiasBuelens]

Indeed, it's easy enough to do in userland, and I'm totally fine with keeping it there:

function followSignal(followingAbortController, parentSignal) {
  // 1. If followingSignal’s aborted flag is set, then return.
  if (followingAbortController.signal.aborted) {
    return;
  }
  // 2. If parentSignal’s aborted flag is set, then signal abort on followingSignal.
  if (parentSignal.aborted) {
    followingAbortController.abort();
    return;
  }
  // 3. Otherwise, add the following abort steps to parentSignal:
  const onAbort = () => {
    // 3.1. Signal abort on followingSignal.
    followingAbortController.abort();
  };
  parentSignal.addEventListener('abort', onAbort, { once: true });
  // Non-standard: if followingSignal becomes aborted for some other reason,
  // remove the abort steps from the parentSignal.
  followingAbortController.signal.addEventListener('abort', () => {
    parentSignal.removeEventListener('abort', onAbort);
  });
}

That said, I wouldn't mind having this exposed as AbortController.prototype.follow(signal) if there's enough interest. 🙂

[noseratio]

That said, I wouldn't mind having this exposed as AbortController.prototype.follow(signal) if there's enough interest. 🙂

Yes please! :) Coming from .NET, I use hierarchical cancellation all the time, it's very handy. I currently do it with CancellationTokenSource(linkedTokens?) from @rbuckton's Prex.

[MattiasBuelens]

I just realized that if we have #911, this could be simplified(?) to:

  // 3. Otherwise, add the following abort steps to parentSignal:
  parentSignal.addEventListener('abort',  () => {
    // 3.1. Signal abort on followingSignal.
    followingAbortController.abort();
  }, {
    once: true,
    signal: followingAbortController.signal
  });

It's abort signals all the way down! 😆