Do await statements unblock synchronously?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Do await statements unblock synchronously?

#!/JoePea
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Do await statements unblock synchronously?

Andrea Giammarchi-2
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Do await statements unblock synchronously?

Jordan Harband
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Do await statements unblock synchronously?

Mark S. Miller-2
Not necessarily "the next tick", but some future tick. Definitely not in this tick or the tick in which the promise is resolved. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Do await statements unblock synchronously?

Mark S. Miller
On Mon, Apr 11, 2016 at 9:31 PM, Mark S. Miller <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Do await statements unblock synchronously?

#!/JoePea
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, and so should always run in a 3rd tick separate from those
other two?

On Mon, Apr 11, 2016 at 1:36 PM, Mark Miller <[hidden email]> wrote:

> On Mon, Apr 11, 2016 at 9:31 PM, Mark S. Miller <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]> 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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>   Cheers,
>   --MarkM
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Do await statements unblock synchronously?

Mark S. Miller
Essentially yes. Minor issues inline

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



--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Do await statements unblock synchronously?

#!/JoePea
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 <[hidden email]> wrote:

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