Host integration

[annevk]

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]

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

[annevk]

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

[littledan]

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]

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]

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

…

On Thu, May 2, 2019 at 08:13 Anne van Kesteren ***@***.***> 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 <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAXLUK2OBALOCB3BTKPVG3PTLLF5ANCNFSM4GWLXYZA> .

[littledan]

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

[littledan]

HTML integration PR: whatwg/html#4613

[littledan]

Per whatwg/html#4613 (review) , 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 whatwg/html#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]

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.