Do await statements unblock synchronously?

/#!/JoePea joe at trusktr.io
Mon Apr 11 21:44:54 UTC 2016


Thanks!

> "tick" is equivalent to our "turn" or "job".

I thought about that, but figured tick was fine since Node has
`process.nextTick`. I'll stick to "turn".

On Mon, Apr 11, 2016 at 2:41 PM, Mark Miller <erights at gmail.com> wrote:
> Essentially yes. Minor issues inline
>
> On Mon, Apr 11, 2016 at 10:32 PM, /#!/JoePea <joe at trusktr.io> wrote:
>>
>> So just to clarify, the code following an await statement should never
>> run in the tick in which the await statement is executed, should never
>> run in the same tick in which the promise it is awaiting gets
>> resolved,
>
>
> Settled.
>
> If unresolved promise p becomes resolved to unresolved promise q, then p is
> resolved but not settled.
>
> If q is then fulfilled or rejected, then q is settled and p is settled in
> the same way.
>
>>
>> and so should always run in a 3rd tick separate from those
>> other two?
>
>
> It should always run in a tick after the ticks in which those other two
> events happen. However, to be fully pedantic, those other two events may
> happen in one tick, so the post-await computation, happening after both,
> would happen in a second tick.
>
> Btw, I assume your "tick" is equivalent to our "turn" or "job". Tick is not
> bad but neither is it clearly better. We should not introduce a third term
> since we already have more than we need.
>
>
>>
>>
>> On Mon, Apr 11, 2016 at 1:36 PM, Mark Miller <erights at gmail.com> wrote:
>> > On Mon, Apr 11, 2016 at 9:31 PM, Mark S. Miller <erights at google.com>
>> > wrote:
>> >>
>> >> Not necessarily "the next tick", but some future tick. Definitely not
>> >> in
>> >> this tick or the tick in which the promise is resolved.
>> >
>> >
>> > Meant: "or the tick in which the promise is settled."
>> >
>> >
>> >>
>> >> Definitely in its own tick.
>> >>
>> >> And yes, engines can always do whatever unobservable optimizations they
>> >> want.
>> >>
>> >>
>> >> On Mon, Apr 11, 2016 at 6:00 PM, Jordan Harband <ljharb at gmail.com>
>> >> wrote:
>> >>>
>> >>> As I understand it, `await` always fires in the next tick, if it's
>> >>> observable.
>> >>>
>> >>> The opportunity to optimize that to "same tick" exists if an engine
>> >>> can
>> >>> prove it's not observable.
>> >>>
>> >>> On Mon, Apr 11, 2016 at 9:54 AM, Andrea Giammarchi
>> >>> <andrea.giammarchi at gmail.com> wrote:
>> >>>>
>> >>>> > I suppose I'm asking for cases where the await statement's promise
>> >>>> > is
>> >>>> > unresolved.
>> >>>>
>> >>>> isn't that a "forever pending"? then AFAIK it should "forever await"
>> >>>> ...
>> >>>> right?
>> >>>>
>> >>>> On Mon, Apr 11, 2016 at 5:50 PM, /#!/JoePea <joe at trusktr.io> wrote:
>> >>>>>
>> >>>>> Is code that follows an await statement supposed to get executed in
>> >>>>> the same tick in which the statement's awaited promise is resolved?
>> >>>>> F.e.:
>> >>>>>
>> >>>>> ```js
>> >>>>> let resolve = null
>> >>>>> const somePromise = new Promise(r => resolve = r)
>> >>>>>
>> >>>>> ~async function() {
>> >>>>>   await somePromise
>> >>>>>   doSomething()
>> >>>>> }()
>> >>>>>
>> >>>>> // ... time passes
>> >>>>> resolve()
>> >>>>> ```
>> >>>>>
>> >>>>> Should `doSomething()` fire in that same tick as when `resolve()` is
>> >>>>> called? I already know that if this is true, there's at least one
>> >>>>> exception: `await Promise.resolve()`, in that the await statement
>> >>>>> must
>> >>>>> still defer to a future tick even though the given Promise is
>> >>>>> already
>> >>>>> resolved. I suppose I'm asking for cases where the await statement's
>> >>>>> promise is unresolved.
>> >>>>>
>> >>>>> - Joe
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >>     Cheers,
>> >>     --MarkM
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >
>> >
>> >
>> > --
>> >   Cheers,
>> >   --MarkM
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>
>
>
>
> --
>   Cheers,
>   --MarkM


More information about the es-discuss mailing list