search

tc39 / proposal-atomics-wait-async

"asynchronous atomic wait" for ECMAScript
https://tc39.github.io/proposal-atomics-wait-async/
Other
89 stars 18 forks source link

Host integration #6

Open annevk opened 5 years ago

annevk commented 5 years ago

It seems for this to work you effectively need to queue a task (for HTML integration) from which to resolve the promise. As promises cannot be resolved "out of nowhere".

lars-t-hansen commented 5 years ago

Presumably this remark pertains to the comment in the spec prose, "(Spec details TBD.)", for section 24.4.1.10 in PROPOSAL.md.

annevk commented 5 years ago

Ah, yes, though I mostly inferred it from "Implementation challenges".

littledan commented 5 years ago

In terms of the proposed spec text in NotifyWaiter, the step to update is probably 16.a, which just resolves the Promise. Rather than just calling the resolve function (how could we do that?! this would be happening synchronously from the agent that called Atomics.notify!), it could call a host hook which queues a task to do the call.

I wonder, should we make a general host hook for JavaScript to queue a task to do something, or should we make individual host hooks per action enqueued? This also comes up for WeakRefs. Or, should we use some more generic mechanism (e.g., an interpretation of job queues at the HTML level)? This question isn't really Atomics.waitAsync-specific, so I'll try to raise it at the next TC39 meeting in the event loop discussion (which was delayed from the previous meeting).

For now, maybe it'd be best to make that line indicate it's a TODO, rather than be falsely precise.

A separate host integration concern is the definition of the timeouts. This isn't really new issue, as it's already present with Atomics.wait. But HTML has a definition of how the timeout clock works in step 15 of the timer initialization steps algorithm. Is this how atomics work too? (I'm not exactly sure how to write a test to trigger the conditions mentioned in HTML.)

Editorially, it'd be great to have just one notion of cancellable timers/alarms, rather than two parallel ones. I don't have a strong opinion of where we put it, but it might be easier in the embedder, to let embedders insert their own defintion of what it means for time to pass (as HTML does, but I imagine other embedders may have their own definitions).

annevk commented 5 years ago

I think we should not do a general hook until HTML really knows what it needs to get and JavaScript knows what flexibility it needs. I.e., let's copy-and-paste a simple HostPleaseQueueSomething pattern a few times and iterate before generalizing.

For timeouts, let's split that into a separate issue? If you could state what you'd like to test I might be able to help or pull someone in who can help. Thanks!

syg commented 5 years ago

Could you point me to an exemplar I can copy from?

On Thu, May 2, 2019 at 08:13 Anne van Kesteren notifications@github.com wrote:

I think we should not do a general hook until HTML really knows what it needs to get and JavaScript knows what flexibility it needs. I.e., let's copy-and-paste a simple HostPleaseQueueSomething pattern a few times and iterate before generalizing.

For timeouts, let's split that into a separate issue? If you could state what you'd like to test I might be able to help or pull someone in who can help. Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-atomics-wait-async/issues/6#issuecomment-488649186, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAXLUK2OBALOCB3BTKPVG3PTLLF5ANCNFSM4GWLXYZA .

littledan commented 5 years ago

@syg It's still a work in progress, but I'm doing something similar for WeakRefs, see https://github.com/tc39/proposal-weakrefs/pull/86 and https://github.com/whatwg/html/pull/4571 , see HostCleanupFinalizationGroup/CleanupFinalizationGroup.

littledan commented 5 years ago

HTML integration PR: https://github.com/whatwg/html/pull/4613

littledan commented 5 years ago

Per https://github.com/whatwg/html/pull/4613#pullrequestreview-237208503 , I think we have a Stage 3 level of support for HTML integration.

A nice-to-have for host integration would be unifying how timers work, as in https://github.com/whatwg/html/issues/4591 . However, I don't think this should block Stage 3 or 4, as this proposal is no worse than the previous state.

ByteEater-pl commented 4 years ago

Why does step 5 of Suspend say "suspend W for up to timeout milliseconds", not "at least"? With setTimeout and similar APIs in other platforms it's at least. That's the only guarantee which can be given (and not exceeding it too much as best effort only) because of various and often unpredictable delays (unless running on a hard real-time system). With current spec, if I understand it correctly, the suspension time can be arbitrary (even 0, that also satisfies "up to") because the delay in step 5 is added to the unspecified time it takes to complete the other steps.