proposal-async-iterator-helpers
proposal-async-iterator-helpers copied to clipboard
Behavior of `.return()`ing, concurrency-wise
As described in the README.md
's "Concurrency" section, and also as been discussed a lot across the Add a buffering helper issue thread - the helpers are designed to NOT queue up .next()
calls like async generators would, but instead delegate each call over to the source iterator's .next()
as soon as it was made. And I absolutely support this of course.
Now, I'm bringing up this issue for us to consider the effect of calls to a helper's .return()
in the same regard as above - which I didn't see was touched yet 😃
With every async generator today, a call to .return()
gets queued on top of whatever pending .next()
calls were made prior to it (which IMO is inherently problematic since there is no guaranty when the last previous .next()
calls are finally gonna resolve, until which any underlying open resources cannot be released whatsoever). However as for our standpoint here though, I suppose a call to a helper's .return()
should just transparently forward it to the source iterator's .return()
, and consequently resolve (the promise it returns) simply as soon as the source iterator's returned promise is resolved.
That makes sense, right? 🤞🏻