testing for promise shortening?

[dckc]

Is this a reasonable way to test whether we have promise shortening?

test('pipelining?', async t => {
  const hp = new HandledPromise((resolve, reject, resolveWithPresence) => {}, {
    applyMethod: (p, name, args) => console.log({ name, args }),
  });

  const p = new Promise(resolve => resolve(hp));
  await E(p).hello('world');
});

[erights]

To clarify your question, does resolving a normal promise to an unresolved handled promise cause eventual-sends to the normal promise to get handled by the handled promise's unresolved-handler?

For the eventual-send proposal that we wish to get through tc39, yes.

For any possible shim implementation on any current JS engine (including v8 and xs), no.

As a result, those messages fail to be pipelined. Currently, to get reliable pipelining of messages eventually-sent to unresolved remote promises, you must carefully ensure that there are no normal promises between the immediate message target and the vat boundary. This is hard but not impossible.

Did we hit a motivating case?

[dckc]

@erights writes:

Did we hit a motivating case?

yes: #4398 (comment)
(not a lot of detail there, but it marks the time etc.)

[mhofman]

If we could have hooks in the engine to ultimately discover when a result promise (like the return value of a native async function) adopts another promise (like an explicit HandledPromise from an E().foo() call), then we could implement pipelining in a shim.

A strawman API would be something like:

class PromiseAdoptionRegistry {
  constructor(onAdoption: (adopter: Promise, adoptee: Promise) => void);
  registerAdopter(adopter: Promise);
  registerAdoptee(adoptee: Promise);
}

Then you could do:

  const adoptionRegistry = new PromiseAdoptionRegistry((adopter, adoptee) => {
    assert(adopter === p && adoptee === hp);
    console.log('adopted');
  });

  const hp = new HandledPromise((resolve, reject, resolveWithPresence) => {}, {
    applyMethod: (p, name, args) => console.log({ name, args }),
  });
  adoptionRegistry.registerAdoptee(hp);

  let resolveP;
  const p = new Promise(r=> { resolveP = r; });
  adoptionRegistry.registerAdopter(p);

  resolveP(hp); // prints 'adopted', likely in a new turn

[erights]

Since you could then simply do it to any promise without any further permissions, this grants too much authority. It is revealing info to an unprivileged consumer of a promise that is not that consumer's business.

[mhofman]

That API requires to hold both the adopter and adoptee promises to know when the former has been resolved to the pending latter. What authority does it reveal? We could make it so the adoptee promise is more entangled with the registry, to ensure that the user of this API has resolution authority over the adoptees?

Since the adopter's settlement is now tied to the adoptee's resolution, this API simply informs the adoptee's owner that resolving the adoptee will also resolve that adopter promise that it already knew about (since the adopter has to be explicitly registered too)