{Audio,Video}Stream: use AsyncIterableIterator#272
Conversation
🦋 Changeset detectedLatest commit: aeb27e1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
nbsp
force-pushed
the
nbsp/audiostream/iterator
branch
2 times, most recently
from
513dbff to
aadbf24
Compare
instead of having a typed EventEmitter
nbsp
force-pushed
the
nbsp/audiostream/iterator
branch
from
0daf003 to
8667110
Compare
| return { done: true, value: undefined }; | ||
| } | ||
| } | ||
| return new Promise((resolve) => (this.queueResolve = resolve)); |
There was a problem hiding this comment.
I think this.queueResolve might get overridden before being called?
so the async iterator could get stuck
There was a problem hiding this comment.
the Mutex helper that Théo has mentioned already might make sense here
There was a problem hiding this comment.
could it? i don't think that's the case, it only gets overridden if you call next() twice without awaiting the first one, which you shouldn't do anyway.
There was a problem hiding this comment.
which you shouldn't do anyway.
agreed that it shouldn't be done, but seems like a footgun regardless?
There was a problem hiding this comment.
would it make sense to return a copy of the same promise if next is called twice?
There was a problem hiding this comment.
I'm not sure, I think best case scenario is a promise chain, which is exactly what the Mutex class does.
nbsp
force-pushed
the
nbsp/audiostream/iterator
branch
from
6315094 to
32cf737
Compare
|
Can you do the same for VideoStream? |
nbsp
changed the title
3 participants
instead of having a typed EventEmitter