Stream + async await

[Jan-Ivar Bruaroey]

Right, the proposals went beyond that. In this context though I thought 
T.J. was looking for a control surface in promises. I shouldn't assume.

In any case, the original challenge here seems solved by something like:

```javascript

var wait = ms => new Promise(resolve => setTimeout(resolve, ms));

async function consumeReadableStream(stream) {

   async function read() {
     try {
       for await (const chunk of stream) {
         // do work
       }
     } catch (e) {
       if (e.name != "AbortError") throw e;
     }
   }
   await Promise.race([read(), wait(30000).then(() => stream.destroy())]);
}

```

...assuming .destroy() is overloaded to throw AbortError somehow, a 
detail IMHO. But aren't we digressing?

For me, for-await still seems like a useful paradigm, and I'm not sure 
readability is helped by using linear code to represent non-linear code 
flow.

.: Jan-Ivar :.

On 8/1/17 4:29 PM, Domenic Denicola wrote:
> That is not why.
>
>
> ------------------------------------------------------------------------
> *From:* Jan-Ivar Bruaroey <jib at mozilla.com>
> *Sent:* Aug 1, 2017 3:47 PM
> *To:* es-discuss at mozilla.org
> *Subject:* 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 
>> <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 withdrawn?)
>>
>> -- T.J. Crowder
>>
>> On Mon, Jul 31, 2017 at 6:10 AM, kai zhu <kaizhu256 at gmail.com 
>> <mailto:kaizhu256 at gmail.com>> wrote:
>>
>>     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 30000ms or not at all?
>>
>>     > On Jul 31, 2017, at 7:26 AM, James Browning
>>     <thejamesernator at gmail.com <mailto:thejamesernator at gmail.com>> wrote:
>>     >
>>     > 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, etc
>>     >        */
>>     >
>>     >         if (Date.now() - start > 30000) {
>>     >             throw new Error('30000 ms timeout')
>>     >        }
>>     >    }
>>     >    /* Instead of callbackOnce the returned promise from this
>>     function
>>     > itself can be used */
>>     > }
>>     >
>>     > ```
>>     > _______________________________________________
>>     > es-discuss mailing list
>>     > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     > https://mail.mozilla.org/listinfo/es-discuss
>>     <https://mail.mozilla.org/listinfo/es-discuss>
>>
>>     _______________________________________________
>>     es-discuss mailing list
>>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     https://mail.mozilla.org/listinfo/es-discuss
>>     <https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> -- 
> .: Jan-Ivar :.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170802/f50468e1/attachment.html>