Inconsistent source signal with AbortSignal?

[sefeng211]

TaskSignal has weak reference for a source signal, where as the base class AbortSignal has a weak set for similar concepts.

Shouldn't TaskSignal also use that?

[shaseley]

Priority and abort dependency is separate: the signal created by TaskSignal.any() has 0 or more abort sources, and separately 0 or 1 priority sources (more than one priority source didn't make a lot of sense).

For abort, TaskSignal.any() inherits abort dependency by constructing a dependent signal using the TaskSignal interface in step 1 of create a dependent task signal. This is purely handled by the AbortSignal.any() spec, and we don't need to touch those data structures here.

Priority dependency mirrors what we do in the DOM spec, with some slight differences. As mentioned, there's only a single priority source for a dependent TaskSignal ("source signal"). So to answer the question, we don't use the weak set because (a) priority and abort dependency is separate, and (b) there can only be a single priority source. (Note: while a task signal can only have one priority source, a task signal can be the priority source for multiple other signals).

As an example:

const controller = new TaskController();
const someTaskSignal = controller.signal;

// This "drops" the abort behavior of `someTaskSignal`, but is dependent
// on its priority. The signal's weak set of source signals (DOM) will be
// empty, but its "source signal" (this spec) will be set to `someTaskSignal`.
// Also, `someTaskSignal` will have one dependent signal in its
// "dependent signals" set (this spec) and 0 for abort.
const signal1 = TaskSignal.any([], {priority: someTaskSignal});

// Same as above, but now `someTaskSignal` has a second dependent
// signal for priority.
const signal2 = TaskSignal.any([], {priority: someTaskSignal});

It's a bit confusing given the reuse of naming in this spec, but the AbortSignal state is private (not exported), and we don't reach into that in this spec. There's an open issue about trying to avoid the duplication, which I'm trying to figure out as I'm working to upstream this, but might do it as a follow-up PR. TBD.

[sefeng211]

Thanks Scott, it makes sense now. I am happy to close this and #118, or do you want to leave them open to address the confusion?