Add the HostResolveInAgent host hook

[syg]

@littledan @annevk For the promise issue raised in #6. How does this look?

Alarms will be in a separate issue.

[annevk]

What can value be besides null? Does it need serializing/deserializing?

Also, it seems a little weird the other agent holds the capability for a promise created in the agent that invoked the method. Currently there's no defined mechanism for promise capabilities to be exchanged this way I think. Not really a problem in the abstract per se, but if we ever are to dig deeper in some way it might come up.

[syg]

What can value be besides null? Does it need serializing/deserializing?

It's always a string. Inter-agent promise resolution would be either "ok" or "timed-out".

Also, it seems a little weird the other agent holds the capability for a promise created in the agent that invoked the method. Currently there's no defined mechanism for promise capabilities to be exchanged this way I think. Not really a problem in the abstract per se, but if we ever are to dig deeper in some way it might come up.

Interesting. Need to think on this a bit.

Edit: I misunderstood the question and spoke too soon. The waiter list stuff are handwavy "semantic objects" that are cluster-wide and are accessible under mutual exclusion (EnterCriticalSection and LeaveCriticalSection) by all agents. Do you think that should be made less handwavy?

[annevk]

I don't think I have a problem with this setup then, assuming we don't need a handle on an actual promise object to resolve it when we have access to a promise capability. (The main worry here is whether it's okay if others copy this pattern and to what extent it needs formalizing as a thing that can be moved between agents.)

[syg]

The challenge here is to spec the host interface in such a fashion to avoid both

1. Touching objects from another agent.
2. Pushing any of the fairness guarantee mechanics around dequeuing from the waiter list into the host.

I'll rework this PR. Currently thinking of, I guess, some notion of handle for PromiseCapability instead of directly using PromiseCapability. Is there any prior art here?

[annevk]

I'm not sure if this helps, but web platform specifications have a pattern that looks something like this:

1. Let x be a new promise.
2. Run these steps in parallel:
   1. Queue a task to resolve x.
3. Return x.

Which passes the reference to the promise to a different thread (that's what "in parallel" does) without getting into the details of how an implementation might have to do that. I'm not sure that's necessarily great though and there might be some problems hiding there that haven't been suitably addressed as of yet.

---

Another thing I noticed is that this passes an agent signifier to the host, which HTML doesn't really talk about at the moment, but that shouldn't be too hard to add. I guess it also means that the abstract operation is scoped to an agent cluster as an agent signifier is only guaranteed to be unique within one of those. (Though see tc39/ecma262#1443, given we sometimes have cross-agent-cluster communication perhaps a globally unique signifier isn't too bad.)

[littledan]

Note, not touching the Promise capability from another agent isn't really about layering with embedders; it's something that's good to maintain just in the JavaScript specification by itself; I imagine implementations will use such a factoring as well. I think we should be calling a host hook from the same agent simply to enqueue the work to resolve the Promise, and nothing more.

[annevk]

Interesting, so both HTML and JavaScript would be responsible for inter-agent communication. I guess that's how it is already to some extent.

[littledan]

inter-agent? Well, this is the world we're living in with Atomics.notify, which already provides an inter-agent communication mechanism at the JavaScript level. I'm just suggesting, we should continue to take responsibility for this in JS, with a clean separation between the inter and intra agent data structures.

[littledan]

I'm not sure this explains much more. Do you have a draft of how this would work on the HTML side?

[syg]

I don't know how this would work on the HTML side in terms of spec. Help appreciated here.

How I want it to work is the following. To keep the fair scheduling semantics entirely contained within this spec, ecma262 needs to be able to handle promises created by other agents. Since that's not kosher, ab70f1f introduces the PromiseCapabilityHandle indirection. On the HTML side, I imagine the same restriction is there: one agent can't directly touch another agent's promise. Since the calling agent that invokes HostResolveInAgent often isn't the target agent that needs to resolve the promise, HTML would need the following abilities:

1. Dereference the PromiseCapabilityHandle to an actual promise in a particular agent differing from the calling agent.
2. Queue a task for resolving the actual promise from 1 in a particular agent differing from the calling agent.

Do those capabilities exist?

Edit: Moreover, HostResolveInAgent needs to preserve ordering. For a particular agent, promises must be resolved in the order in which they were received.

[annevk]

As I mentioned above, what HTML does is that it passes a variable for a promise across boundaries, but only fulfills it where it was created from a task.

If ECMAScript wants an abstract handle it should also offer a feature available on agents for mapping that abstract handle to a concrete object I think. If ECMAScript provides that HTML would be able to do all the things needed.

[syg]

I reverted the handle business since I understood the no-cross-agent-touching to be more restrictive than it was. The JS side of things doesn't access another agent's promise capability except to pass it to the host hook.

[littledan]

Corresponding HTML PR: whatwg/html#4613

[littledan]

The current text fits in just fine with whatwg/html#4613 . I'd land this PR, and iterate later if we get feedback on the HTML PR.