await on synchronous functions

Fri Jul 17 19:50:43 UTC 2015

Going back to my original question, suppose I write this:

for (let fn of myFunctions) {
  let result = await fn();
  // Do something with result.
}

If all the functions happen to be synchronous and take a while to complete,
am I blocking the event loop?
I think what I'd like to happen is for each call to happen in the next pass
through the event loop.

On Fri, Jul 17, 2015 at 2:44 PM, Ben Newman <benjamin at cs.stanford.edu>
wrote:

> Having addressed (1) earlier, perhaps by mistake, my thought on (2) is
> that you probably want await f() to work the same way if f() just happens
> to return a Promise, as when f is actually async, but there is no way to
> know, in general, if some arbitrary function will or will not return a
> Promise, so await should treat all arguments in the same way: by calling
> Promise.resolve.
>
> It's an open question whether a sufficiently smart runtime could optimize
> cases when the argument is not a Promise, or when the Promise is already
> resolved, but it would have to do so under the constraint of not revealing
> that optimization to the user.
>
> On Fri, Jul 17, 2015 at 12:36 PM Chris Toshok <toshok at gmail.com> wrote:
>
>> I think we're confusing two different cases here:
>>
>> 1) usage of `await` in the body of a function that is not itself marked
>> as `async`
>> 2) usage of `await f()` where `f` is not marked as `async`.
>>
>> 1 is easy to mark as an early error (and should be imo).  2, not so much
>> (and is what Mark was asking?)
>>
>> -c
>>
>>
>> On Fri, Jul 17, 2015 at 12:30 PM, Ben Newman <benjamin at cs.stanford.edu>
>> wrote:
>>
>>> If we stick with the rule that await is only regarded as a keyword if it
>>> appears in the body of an async function, then await x without async is
>>> simply a syntax error, and we can avoid having to answer this question!
>>>
>>> That said, perhaps a more natural way of handling wayward await
>>> expressions is to treat them as referring to the closest enclosing async
>>> function on the call stack (not necessarily the immediate enclosing
>>> function), throwing an exception if there is no async function on the
>>> stack. Then any await expression would delay the resolution of the Promise
>>> returned by whatever async function is currently executing. The
>>> same-function-body syntax restriction is a special case of that more
>>> general model (and notably easier to implement by transpiling to
>>> generators!).
>>>
>>> Generalizing async/await in this way turns out to be equivalent to
>>> introducing coroutines into the language, and while I would love to see
>>> that happen one day (it would greatly simplify writing parallel forEach
>>> loops, for example), it would require substantial changes to the execution
>>> model of the language.
>>>
>>> Here are some slides from a talk I gave earlier this year about the
>>> benefits and pitfalls of coroutines, in case you're interested:
>>> http://benjamn.github.io/goto2015-talk
>>> On Fri, Jul 17, 2015 at 11:35 AM Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>
>>>> > Think about a large program where you refactor a single async
>>>> function to no longer be async
>>>>
>>>> did that ever happened in the history of logic? I am actually curious
>>>> to understand a single valid case where that would be a solution to any
>>>> problem.
>>>>
>>>> Apologies if I can't see your point but we've been talking about
>>>> "Promise must Promise" so much this answer was absolutely unexpected.
>>>>
>>>> Thanks for any sort of clarification
>>>>
>>>> On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem <tomvc.be at gmail.com>
>>>> wrote:
>>>>
>>>>> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi <
>>>>> andrea.giammarchi at gmail.com>:
>>>>>
>>>>>> If I might, if there's one thing that has never particularly shone in
>>>>>> JS, that is consistency.
>>>>>>
>>>>>> I see only two possibilities here: 1) it throws with non Promises 2)
>>>>>> it "Promisify" anything that's not a Promise as if it was a
>>>>>> `Promise.resolve(1)` ... but since there's too much magic in the second
>>>>>> point, I'd rather stick with the first one.
>>>>>>
>>>>>
>>>>> I would be highly in favor of (2). Think about a large program where
>>>>> you refactor a single async function to no longer be async. Then I see no
>>>>> reason why I should be forced to refactor all of its callers to remove the
>>>>> await keyword. Going from sync to async requires refactoring because you're
>>>>> introducing new potential interleaving hazards, but any code that is
>>>>> already prepared to work with async functions (or promises in general)
>>>>> should work equally fine on immediately resolved promises.
>>>>>
>>>>> regards,
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Just my quick thoughts
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith <zenparsing at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I know the spec for this isn't finalized, but what is the current
>>>>>>>> direction for the behaviour when await is used on a function that is not
>>>>>>>> marked async and doesn't return a Promise? Should it run immediately or
>>>>>>>> wait for the next turn of the event loop?
>>>>>>>>
>>>>>>>
>>>>>>> More generally, the question is: what should await do for
>>>>>>> non-promises?
>>>>>>>
>>>>>>>     await 1;
>>>>>>>
>>>>>>> Should it force a job to be queued?
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> es-discuss mailing list
>>>>>>> es-discuss at mozilla.org
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/14109b8a/attachment.html>