Agoric ECMA TC39, TC53 presentations, 4 Oct 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Eventual Send: JS Support for Promise Pipelining

Description

Presented at TC39 Oct 2019. https://github.com/tc39/proposal-eventual-send
Achieved stage 1 status.
Slides:
https://github.com/tc39/agendas/blob/master/2019/10.eventual-send-as-recorded.pdf

This proposal adds eventual-send operations to JavaScript Promises, to express invocation of operations on potentially remote objects. We introduce the notion of a handled Promise, whose handler can provide alternate eventual-send behavior. These mechanisms, together with weak references, enable the creation of remote object communications systems with promise pipelining. This proposal is not specific to any one remote object system. Instead, it specifies a general mechanism for hooking in whatever host-provided remote communications facilities are at hand, without constraining the nature of those facilities.

A

So this is the eventual send proposal proposing an new API which recall handled promised to enable a distributed promise pipeline.

A

Let's understand this proposal in the historical context of the promises that we have, which came in with es6, so the history that got us to es6 promises.

A

Was that they started with the promises of the e language and the cap, TP protocol kept TP capability transport protocol.

A

These were the first non-blocking promises they're the direct ancestor of the promises we've got.

A

They were designed for primarily for doing distributed, object, community computation, sending remote messages to remote objects in a secure and efficient manner. Among.

A

Individual units, which were communicating which were event loops, so this was the communicating event loop, concurrency model javascript is essentially a system of communicating event loops and the the e design first made it into javascript. With the water came QAPI the water can queue. Api then became the widely adopted variant done by Chris Cole and Dominic de Nicola also called the queue API that that led directly to the 2011.

A

The FEMA script, promises proposal that, in turn, turned into the the promises we have a neck mascara six. The system shown in white here, the I'm using the white color to India the systems that were designed to support distributed, promise, pipelining I'll be explaining shortly. What promise pipelining is, but these systems that did distributed objects did it with distributive promise pipelining and they gotten tremendous payoff from supporting promise. Pipelining correctly, the reason the cute cannon, so the queue API itself didn't do distributed distributed messages, but it was built to be extensible and Chris.

A

Koalas wrote the queue connection extension that used the extension hooks to extend it over the network in a way that did promise pipelining. The queue connection is colored yellow here, because it was not practical for reasons that I'll get to shortly.

A

Separately, Dean Tribble went off to Midori and went oh sorry, went off to Microsoft and did the Midori project the Midori project applied the same kind of distributed asynchronous non-blocking promises with promise pipelining do really quite significant large-scale systems that were very high performance and showed that this model really is a scalable model and they were reporting performance speeds up, speed, ups, going from system without promise pipelining to one with promise, pipelining performance, speed.

A

Ups between ten and a hundred on real cases, the Midori use of promises inspired the async weight in c-sharp, which, in turn inspired the the async weight functions that we have in ACMA script today.

A

Another path by which the II promise design made it into JavaScript was by the twisted Python library for doing asynchronous local asynchrony, combined with the full SCAP protocol for doing distributed capability remote messaging. But this one's not colored white, because it didn't get promised pipelining right. It didn't get promises quite right either it led to a bunch of javascript work that ended up being a dead end. So enough on that also a cabin proto is using the en cap.

A

Tp promise pipelining design and again shows that this is has a lot of very important payoff in large-scale distributed systems. Captain proto is a is based on essentially protobufs to do distributed capability based remote messaging with promise pipelining.

A

Okay, the reason why q connection was not practical, there's also the reason why the features of the 2011 proposal that support distributed computing have been sitting on the shelf all this time, which is the lack of weak references. If you try to do this kind of distributed, object computing without weak references, you end up with a huge memory leak that you cannot solve the bookkeeping that you have to do on each side of a connection to keep track of how you locally address a remote object.

A

How you register remote object so that it's an object so that it can be remotely addressed those tables just grow without bound with that weak references. You cannot find out that it's safe to remove an object from those tables, so so the rest of this has been sitting on the shelf till now, because we haven't had weak references now that weak references have proceeded to the point that they're inevitable it's time to revive the rest of the original dream.

A

As you say, by the way that neither promises nor weak references themselves originated with Ian Capp TP, it's the non-blocking promises that originated an E and it's the weak references with our design about post mortem finalization happening in turn, boundaries that originate an e. So so I want to be. You know clear about what what I am and am NOT claiming originates in E itself.

A

So the es 2011 proposal, the the promises themselves, had an extension hook in them and there were the extension hook. That was approximately the extension hook. That cue connection used to extend the cue promises across the across the network and our return. Promises don't have that extension hook and this proposal is proposing to provide that extension hook and to provide it in a way that fits with the promises we've got, which are somewhat different than the 2011 promises.

A

We reworked particulars of the API to fit into modern promises, but it's essentially the same idea, and you can think of this idea as an as having many analogies to the way that we introduced proxies into es6 in es5, we had a bunch of eternal methods that were just internal expository devices to introduce proxies.

A

We turned those extra those methods into things that, on a proxy, would cause a trap to a corresponding method on a handler so that various behaviors on that object would normally provide for itself.

A

The behavior on a proxy could be provided by handler, so we're proposing a new abstraction called a handled promise and a new constructor named handle promise that takes some new operations, which we're also proposing and has regular promise versus handle promise differ with regard to how those new operations work crucial, we're not proposing to change any of the behaviors of any of the existing operating any of the existing promise api- we're not touching in particular, then or catch or finally, in any existing methods on promise. Yes, mall tomorrow, yes,.

B

This really confused, but that handles who was a synonym for results.

A

B

You buy the result: okay,.

A

Thank you. I completely, did not anticipate that possible misunderstanding. So thanks for clarifying that and and you're exactly right, it's it's. It's completely orthogonal both promises and both regular promises and handle promises can be pending or fulfilled, or rejected, and/or resolved to other promises. So so all all of the states of a regular promise. All of those states are also reflected enhance the promise.

A

So with these enablers, together with the weak ref and the handled promise being the only absolute ones, hence the solid lines, but the things like the the understanding of object, IDL's from captain proto things like the Ekman script, async functions, which we have, which help all of these things, combined together to enable third-party libraries to create pleasant, distributed JavaScript systems- I we are. This proposal is not proposing a a particular form of distributed javascript language, a particular interpretation of what a distributed JavaScript language is. It's not.

A

It's also not saying that the only use of these extension points is to make a distributed javascript. This is sort of the test case of adequacy. If this proposal is, can you build a distributed JavaScript in third-party libraries, given just these extension points and at a gorrik? We have using exactly this. What we're proposing.

A

So, to give a first introduction to first intuition about what promise pipelining is about I'm, going to peek ahead and use for expository purposes, the wavy dot syntax, which is not part of this proposal, but is part of the next proposal I'll be presenting here, but the wavy dot. Syntax is just syntactic sugar for.

A

Doing an eventual send of a message to a remote object, so the idea here is that lets say the disc is a local variable that somehow represents a remote object. In particular, it's a ittle. It's a root. It's a it's! A remote promise that that designates. That represents some object. That's that's remote and obviously from the name, it's disk-like! So it's! Let's say it responds to an open directory message where it gives you back a remote object that acts like a directory.

A

The directory responds an open file message and gives you back an object that that acts in a file like manner that responds to a read message, and if you do this with convention, without promise pipelining in a conventional RPC like manner, then this is three round-trips with promise pipelining. It takes advantage of the nature of promises, which is when you send off the open directory message. You immediately get back a promise for the result.

A

It's an unresolved promise because you don't know what the result is, but you have that promise you're, sending the open file message to that promise. So if that promise, that unresolved promise could be handled by your communication system in such a way that it can, it can serialize the open file message to be sent to the same remote destination at which the open directory message is going to be resolved.

A

Then you can likewise with a read. Then you can, then all three of these messages can go out without a roundtrip, and the entire thing is just one round-trip waiting for the results of the read.

A

So, to illustrate what's going on, what's the best you can do without promise pipelining, let's first of all, imagine a classic RPC system where, where you have blocking method calls, so the line and top is clearly equivalent to the three lines below it: calculating t1, t2 and t3.

A

The obviously JavaScript doesn't have some synchronous blocking call, so it's more realistic for JavaScript would be something like it, but using awaits everywhere and if you did it with the weights or or like our weights, or you can just consider them syntactic sugar for then so the best you can do with JavaScript today is to plumb this kind of thing together using the weights or thenns and the best you can do. If you do it.

A

That way is that when you send off the a message to X, what you have is an unresolved promise for the result and any attempt to do a dot then or in a weight on that promise necessarily waits until we know what the result is. We we have to wait until it gets delivered and produces a result before, and a weight on on. P1, which is the third line, is the important one you wait on. The weight on p1 has to fire before we can send the C message.

A

Now the a message sent to X and the B message sent to Y those could proceed in parallel, but the but the crucial round. True so so. This is two round-trips rather than three, but the round-trip you can't avoid. If you just you waiter, then, is that P one has to be resolved before you can. You can express the sending of c22 what it resolves to.

A

With handled promises, there's the again the issue of expository syntax, because I haven't yet presented the API.

A

What we show here on the left is one way to write it without it, without introducing new syntax using a little proxy based helper, that I'll be discussing more in the next presentation, but I think that for expository purposes, I am gonna, go ahead anyway, and jump ahead to the wavy dot syntax, so the wavy dot syntax. The way to think of it is is, and now it gets to question mark dot if we think of question mark dot as adjective dot that it's like that, but but different.

A

Somehow, wavy dot is also like dot, but different, somehow in particular that if you're sending it to a promise, you're saying this method should eventually be applied to whatever the promise ends up designating and if the promise ends up designating a remote object, then this message should be delivered to the remote object.

A

So once again, the line at the top is equivalent to the three lines at the bottom. The three lines at the bottom, using our new handle, promise API once a goes out before, even before it gets delivered. The promise that you're holding is still an unresolved promise, but it's an unresolved handle promise, likewise with B.

A

So while both of these are still in the air, p1 and p2 gives you the ability to name what will be the results such that you can then do an eventual send of C to p1 and have the handling of the unresolved promise handle that sending op raishin so that it can be serialized onto the network as well. So all of the all three of these things can be streamed out together, depending on the nature of your serialization system.

A

They might end up just getting bundled into one network packet, but they all just go out together and then at some later time they start arriving on the receiving machine, where the receiving machine typically not always, will return an object, local to itself t1 that returns t2 and now, as the messages arrive again with no further network delays. As these message, the message is streamed out on the sending side and then on the receiving side they're streaming in and there and they're typically processed one add one after another immediately as they're streaming, it.

A

So going back to the proxy analogy, the way in which, in order to introduce proxies into es6, we had to go back into the internal methods and refactor them slightly, so that they were suitably defined to be virtualized by trapping to a handler. So we're doing the same thing here. So these are the new internal methods that we're proposing to add to promises and like with proxies, we also introduced the reflect API.

A

So the proxies going to a handler basically lifts the operation and then the reflect API lowers the operation again and and there each of the reflect methods will in turn call one of these internal methods on their first argument. So likewise, here, where these static methods are analogous to the reflect methods, their methods on the static handled promise API and when their first argument, their first argument must be a promise and with and what they do, is they simply invoke the corresponding internal method.

A

When that method is a normal promise in which the fulfilment is a normal local object, then the default behavior of the internal method is just what you would expect by the analogy between wavy dot and dot. It's basically just the postponed to dot operation. So an eventual we'll get is just doing a then on the promise and then doing the the postponed get on what the promised returns and likewise for the others, but I want to call out apply.

A

Method is distinct from what you, from a direct analogy that you see on on proxies and reflect, and that's because in distributed programming by far and away the most common operation, is the method call the JavaScript. You know way of viewing the method call locally. Is that it's a property lookup followed by a function invocation?

A

That's that might be a fine way of looking at locally, but in terms of facilitating a good distributed, protis, tributed and program experience, that's also reasonably efficient. You really want to treat the method call as a distributed. Primitive, oh yeah, Waldemar.

A

The arguments can be promises, I.

A

Had not considered prompt being anything but a string or a symbol.

B

That you just probably meant well.

A

The I was assuming to say: okay, this is not fought out, I'm just going to tell you what was in my head and I think with the way our Shem. We have a Shem for this that we're using in production and agaric. I. Think what our Shem does, which is also what's in my head, is that the square bracket immediately does the same coercion that the square bracket property lookup does in JavaScript, which is no matter what you give it. It goes into two cases.

A

Is it a symbol, if so past the symbol along and otherwise coerce it to a string? But since these are handled and you're talking to something that, on the other side, is not necessarily JavaScript or might be handled through either logic, it's conceivable. We might want to let the handler decide rather than building in a decision up front and I had not considered that question. It's a good one to investigate in phase one.

A

A

We add for each of those internal methods. We add a corresponding internal method that, rather than being named, something send is named something send only with corresponding static methods, etc. And the reason for these is that the send only forms are the ones that you do only for effect.

A

So if you're not interested in the term result, if you're doing it in a context where you're going to ignore the return result anyway, the fact that a JavaScript expression doesn't know whether it's return result is used is normally not terribly costly for a distributed protocol to do all of the bookkeeping to to thread through the returning of a return result in the resolving of the remote promise when it's just going to be ignored is actually quite expensive.

A

It's not more round-trips expensive, but it's extra bookkeeping expensive, so we introduced only variants for when the result will be ignored and you're just interested in the effect and corresponding handler traps, of course, with the with the send only suffix. So this together is all of the handler traps. Oh.

A

One more point about the handler: craps is like with the proxy handler traps. There's a defaulting relationship. If you, if the handler omits an only trap, then it then it defaults to the corresponding non only version and then just ignores the result.

A

If the apply method or apply method send only is absent, it defaults to a composition of get followed by apply function, so it does. It does sort of fall back on the JavaScript notion that a method call is really a property get followed by a function. Call so there's there's a nice defaulting relationship. These things.

A

Okay, so the promise constructor itself there's the on this slide. This is this slide. Here is just a review to set us up for explaining the handled promise, constructor API the promise constructor API.

A

It takes one argument which is a function that in turn, takes a resolve and a reject parameter and the promise constructor returns and an unhandled promise the done' and then the resolve. That's given to that function. Argument is itself something that you give it a resolution and it get end it returns void. It doesn't return anything and likewise reject you. Give it a reason. It doesn't reject anything.

A

What resolve and reject do is they simply change the state of the promise from pending to foot two to fulfilled or from pending to reject it or from from pending directly to pending indirectly, because it's following some other promise. If you resolve one promise to another promise, that's why I say resolve a resolution rather than resolve will fulfillment, because you can resolve a promise to another promise.

A

The handled promise API adds two new.

A

Right adds two new parameters, both of which are optional and if both of them are left out, then the semantics you get is exactly the semantics of the promised constructor one of the things that has been raised a few times, which we can certainly consider an open phase. One question stage: one question is since handle promise devolves to the meaning of promise.

A

If you omit the optional parameters, should we actually introduce a new class, or should we just add these optional parameters to promise I feel pretty strongly that we should not add the optional parameters to promise, because Java scripts looseness with arity makes it very hazardous to add arity to existing API, but it's I can certain. You know, certainly, if I'm happy to to re-examine that question during phase one the the unresolved handle the unfulfilled handler is the thing that handles the promise in while it's in an unfulfilled State.

A

So as you do these various eventual send operations on the promise. If it's a handled promise with an unfulfilled Handler, what happened.

A

It's still showing on the screen here: oh there, it is good. It's back, that the that the craps on the unfulfilled handler get invoked while the handle promises in an unfulfilled state.

A

In order to transition the promise from being in an unfulfilled state to something else, you can call resolve or reject on it, which has exactly the the current meaning or you can call back resolve with presence which is a bit peculiar.

A

It get it and it took us a while to refine this into something that met all the constraints resolved with presence. You give it back a presence handler and it gives you back a fresh empty object. The kind of object that would be made by object, dot, create of not an object with no own properties, no prototype and fully mutable. So it's just an object that you can that the that the code using resolved with presence can mutate pretty much into what it wants.

A

But the key thing is that it's fresh and the reason why the reason why we need to introduce the concept of the presence is I'm gonna back up to.

A

This slide over here.

A

Yeah, let's do that slide over there. So at this point, p1 is a fulfilled promise. If you didn't then on p1, the then should fire the then has to call its callback with the fulfilled value, but the fulfilled value is t1. The fulfilled value, isn't here it's elsewhere. So how can you call the local callback with t1, where you can't so the presence is a remote. Is a local representative of the remote object so that it's a local representative, that's provided to the success callback of the then.

A

A

B

I have an extra ten minutes.

B

There no objections.

A

Okay, thank you.

A

So we do have a sim we're using the shim in production. What, if we can do it with the shim in production? Why aren't we? Why do? Why do we need to come to the committee? Why do we need a new platform feature? Why do we need special help for the platform? Well, there's one hard case that we have not been able to solve and and I've managed to convince myself.

A

That is probably unsolvable purely from a library which is consider this piece of code on line two, we create a new normal platform, promise that's starting off in an unresolved State on line three, we do an eventual send to it of the message foo conceptually. This is buffering the eventual sent in the promise what the shim does is.

A

It uses a weak map to it to keep bookkeeping in a side-table associated with the identity of the promise for buffering the message, but is basically buffering the message that should be delivered to whatever the promise comes to designate. So now it's sitting there in a local promise. Now we create this handled promise queue with an unfulfilled handler and cue is now a handled unfulfilled promise at this stage.

A

If you did an eventual sent to queue that eventual sense should get handled by the unfulfilled Handler and sent over the network. Now, the last line resolves p2q.

A

So the semantics that we want is that all of the messages that were buffered in P now get forwarded to Q and, in this case, turn into a trap on Q's unfulfilled handler, so they can get sent out over the network.

A

We can certainly override in our shim. We could monkey patch, the you know the the the promised constructor 202 money in order to monkey patch. There was the resolve, that's provided in the callback. We could pre-cut monkey patch, the you know a bunch of things, but it's really not feasible to buy monkey patching, intercept every place in the spec that the that the that the that JavaScript resolves a local promise and particularly cause of async functions and wait. It's just not feasible to intercept all resolves, Bulevar.

B

A

The second line, the promise constructor is, is storing into PR the the resolver of okay.

B

A

Be a function calls off here's a function. Oh oh, oh I'm, sorry! Yes, it should be PR open, paren, Q. Exactly yes, I was I. Was this light? Isn't correct? So PR is the resolver for the promise. P that's stored by the promise, constructor online tip, okay and and the last line should just be a function call, but in any case what? If, if the, if the local promise P is resolved in a way that we cannot intercept, then the message foo, the eventual message.

A

Foo is sitting languishing in that promise when it should have been pipelined over the network and eventually we still have. The shim still provides the variant that ever every message ever sent is eventually delivered act exactly once to the the object that the promise designates so, but but that, in this case in our shim will depend on the then firing which means that you're waiting on the roundtrip you are trying to avoid, and not only have you lost promise pipelining you're, also getting a very counterintuitive message order.

A

One of the things that's important in doing distributed programming is to be very careful about predictable orders of message delivery and this. This disrupts both of those and now I'll, stop recording and take further questions.