- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 Jun 2021 10:20:30 +0000
- To: public-webrtc-logs@w3.org
I still see no need for a threading model defining specific threads. The claim that we need a threading model because Web Audio and Web Codecs define one, or this can't ship anywhere is just a faulty generalization fallacy. There isn't a single MediaStreamTrack sink spec defines a threading model, and they all have shipped. The closest would be Web Audio, which does define a threading model, but it does not specify how the Web Audio MediaStreamTrack sinks (MediaStreamAudioSourceNode and MediaStreamAudioTrackSourceNode) and source (MediaStreamAudioDestinationNode) interact with it (at least not explicitly), much like a lot of the other observable behavior of those objects which is also not specified (yet it shipped!) I guess we could put a note somewhere saying that the model is that all operations/algorithms must execute sequentially and that multithreaded implementations must be careful to ensure this property (e.g., to avoid races), but I don't see a strong need for it since that seems to be the default for a lot of specs and they usually don't have this kind of note. For the reasons given above, I'm closing this bug. Now that the spec is using more specific algorithms to define behaviors, please file separate issues if you find ordering problems in them. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/27#issuecomment-863932145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 18 June 2021 10:21:25 UTC