The encoder/decoder configure methods is not using a queue to check for configuration support
youennf opened this issue · comments
Following on web-platform-tests/interop#382 (comment) and web-platform-tests/wpt#42127, we could improve the spec related to the configure methods.
In particular:
- configure should probably be using a parallel queue to check for configuration support, like isConfigSupported is.
- once the check is done and config is not supported, configure could queue a task to call the close decoder/encoder algorithm, like done in https://w3c.github.io/webcodecs/#dom-audiodecoder-decode. This would work nicely if we change the close decoder algorithm to synchronously call the error callback.
Other editorial notes while reading the spec (probably applicable to all decoders/encoders) :
- isConfigSupported is trying to resolve a promise from a parallel queue, we could instead queue a task to resolve the promise.
- [[message queue blocked]] is accessed from both the work queue and the event task queue, for instance in https://w3c.github.io/webcodecs/#dom-audiodecoder-configure. It might be better to queue a task to set [[message queue blocked]] to false and synchronously process the control queue.
- Ditto for [[codec saturated]] which seems to be accessed from both the codec work queue and the event task queue.
@dalecurtis, I filed this issue following on our WPT test discussions.
Let me know if that aligns with your thoughts.
I can also submit the corresponding PR(s) if that helps.
I'm not sure about [[codec saturated]] since that might have performance implications, but the rest sgtm and matches what our implementation (after the recent fixes). Your help with the PRs would be most welcome, thanks!
Additional remark related to [[codec implementation]]as spec says it should only be used from the [[codec queue]].
But the spec currently signals or clears [[codec implementation]] from reset/close algorithms, which can be called from JS directly, without queueing a task to the [[codec queue]].