Stream + async await

Naveen Chawla naveen.chwl at gmail.com
Sun Jul 30 06:16:53 UTC 2017


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 requesting. Do nothing to actually consume the
data
        }
    }

    async startConsumingAsync(){
        for async(const item of requestItems){
            //Consume the item. Here you can also apply "front pressure" to
request the next item if the "request" loop is behind
        }
    }
```

I haven't actually done this so it's just thinking out loud.

Thoughts?

On Sun, 30 Jul 2017 at 03:59 Isiah Meadows <isiahmeadows at gmail.com> wrote:

> 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 can't really be merged
> meaningfully as you would hope. They both represent multiple values over
> time, but one is eager, the other lazy.
>
> On Sat, Jul 29, 2017, 06:54 Naveen Chawla <naveen.chwl at gmail.com> wrote:
>
>> 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 the completion and satisfactory consumption of the last one.
>>
>> Can you suggest a way to trivially invoke some "back pressure" using this
>> construct? By this I mean - invoke extra requests before they come to be
>> consumed (like you can do with reactive streaming libraries). An example
>> use would be if you wanted to do some "eager loading" of data while the
>> user is likely to be viewing but not currently interacting with existing
>> content, for example.
>>
>> You seem very familiar with this construct, so I wouldn't be surprised if
>> you've already thought about this! (If you're too busy I'm sure there are
>> others here familiar with it too!)
>>
>> On Tue, 11 Jul 2017 at 21:09 Domenic Denicola <d at domenic.me> wrote:
>>
>>> https://github.com/tc39/proposal-async-iteration
>>>
>>>
>>>
>>> *From:* es-discuss [mailto:es-discuss-bounces at mozilla.org] *On Behalf
>>> Of *Naveen Chawla
>>> *Sent:* Tuesday, July 11, 2017 09:24
>>> *To:* es-discuss at mozilla.org
>>> *Subject:* Stream + async await
>>>
>>>
>>>
>>> It'd be great to have async stream constructs such as:
>>> http://reactivex.io/rxjs/ , supported natively, such that they can be
>>> used directly with the async / await keywords for async stream programming
>>> in a linear fashion (analogous to what can already be done with linearly
>>> awaiting Promises, but for async streams instead).
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170730/4eac59e4/attachment.html>


More information about the es-discuss mailing list