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 <[email protected]> wrote: > Essentially yes. Minor issues inline > > On Mon, Apr 11, 2016 at 10:32 PM, /#!/JoePea <[email protected]> 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 <[email protected]> wrote: >> > On Mon, Apr 11, 2016 at 9:31 PM, Mark S. Miller <[email protected]> >> > 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 <[email protected]> >> >> 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 >> >>> <[email protected]> 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 <[email protected]> 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 >> >>>>> [email protected] >> >>>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> es-discuss mailing list >> >>>> [email protected] >> >>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> [email protected] >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >>> >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> --MarkM >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> > >> > >> > >> > -- >> > Cheers, >> > --MarkM >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> > > > > > > -- > Cheers, > --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
