Re: Stream + async await

------------ > *From:* Jan-Ivar Bruaroey <j...@mozilla.com> <j...@mozilla.com> > *Sent:* Aug 1, 2017 3:47 PM > *To:* es-discuss@mozilla.org > *Subject:* Re: Stream + async await > > Because a promise is not a control surface of the asynchronous action > fulfilling

Re: Stream + async await

-Ivar :. On 8/1/17 4:29 PM, Domenic Denicola wrote: That is not why. *From:* Jan-Ivar Bruaroey <j...@mozilla.com> *Sent:* Aug 1, 2017 3:47 PM *To:* es-discuss@mozilla.org *Subject:* Re: Stream + async await Because a

Re: Stream + async await

That is not why. From: Jan-Ivar Bruaroey <j...@mozilla.com> Sent: Aug 1, 2017 3:47 PM To: es-discuss@mozilla.org Subject: Re: Stream + async await Because a promise is not a control surface of the asynchronous action fulfilling it; confuses owner with co

Re: Stream + async await

Because a promise is not a control surface of the asynchronous action fulfilling it; confuses owner with consumer. https://stackoverflow.com/a/41417429/918910 .: Jan-Ivar :. On 7/31/17 7:35 AM, T.J. Crowder wrote: Related: https://esdiscuss.org/topic/how-about-awaiting-arrays (particularly

Re: Stream + async await

Related: https://esdiscuss.org/topic/how-about-awaiting-arrays (particularly the discussion of `await.race`), since effectively you're doing a race between a timeout and each chunk. Also relevant is the former work on cancelling promises, now withdrawn. (Can anyone point me at *why* it was

Re: Stream + async await

OK let me correct myself. That's preposterous. You have to `await` a promise to kick off it's process. But my point about being able to assign the promise to a wider-scoped `currentRequestItemPromise` before awaiting it which seems impossible with async iterators, which rejects upon timeout,

Re: Stream + async await

Yes, you need to intervene and reject the latest promise upon timeout (by having a reference to its "reject" callback). This makes me wonder (and I'd like to be corrected if wrong) if async iterators are more of a hindrance than a help? We can currently do a loop over an array of promises,

Re: Stream + async await

the timeout handler will not work as advertised, e.g. what if io / db issues causes a network stream to intermittently respond in intervals far greater than 3ms or not at all? > On Jul 31, 2017, at 7:26 AM, James Browning wrote: > > It'll look something like

Re: Re: Stream + async await

It'll look something like this: ```javascript async function consumeReadableStream(stream) {     const start = Date.now()     for await (const chunk of stream) { /* Do whatever you want with the chunk here e,g, await other async tasks with chunks send them off to wherever,

Re: Stream + async await

so that everyday programmers can relate, can someone give a code-snippet of the proposal equivalent to the common-use nodejs example below? ```javascript function consumeReadableStream(stream, consumeChunk, callback) { /* * stream - readable stream * consumeChunk - has signature - function

Re: Stream + async await

Guys! I thought of a way of doing this. Roughly it's having 2 loops, one for consumer and one for requester. Would this work?: ``` startRequestingAsync(); startConsumingAsync(); async startRequestingAsync(){ for async (const item of requestItems){ //Control the

Re: Stream + async await

There's also this strawman of mine which deals with most things async, but it has several of its own issues that I haven't quite addressed (complexity still being one after a week straight): https://github.com/isiahmeadows/non-linear-proposal I will caution that async iteration and observation

RE: Stream + async await

omenic Denicola<mailto:d...@domenic.me>; es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> Subject: Re: Stream + async await Interesting!!! Excuse my ignorance, but with this construct, how would you trivially invoke a "publish" ahead of any given "consumption"

Re: Stream + async await

Interesting!!! Excuse my ignorance, but with this construct, how would you trivially invoke a "publish" ahead of any given "consumption"? As far as I can see, ``` for await (const item of requestItems){ } ``` on its own is purely a "front-pressure" construct. That is, each request is made upon

RE: Stream + async await

https://github.com/tc39/proposal-async-iteration From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Naveen Chawla Sent: Tuesday, July 11, 2017 09:24 To: es-discuss@mozilla.org Subject: Stream + async await It'd be great to have async stream constructs such as: