-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
asyncFlow should directly support E
via promise handlers
#9299
Comments
Although this support will likely happen after #9097, it needs to happen before we commit to durable log state on chain, since this |
If #9301 has already happened without |
Capturing here what @mhofman wrote at #9097 (comment) When supporting E, the handler is given a resultP for send operations. That resultP is the guest promise, and the result promise returned by the send handler is adopted by that promise, so the resolvers of the returned promise can be mapped to the resultP guest promise. The bijection can map the resultP guest promise to the host vow / result promise of the actual eventual send performed on the host object. |
closes: #XXXX refs: #9299 #9322 ## Description Prepare for #9322 by making any guest use of `E` until then cause an error. We expect that it might be a while before #9322 is ready for review. By merging this PR soon, we prevent any guest code or logs that would commit us to an incompat way of handling `E`. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations Should document that guests cannot invoke host vows or remotables with `E` until #9322 , which won't happen immediately. ### Testing Considerations - [x] need to test what kind of error state this goes into. Should be a panic, so that an upgrade can unblock guest execution that got stuck trying to `E`. ### Upgrade Considerations The point. By making such use of `E` an error now, we ensure that #9322 can proceed without causing any compat problem with committed durable state. Co-authored-by: Mathieu Hofman <86499+mhofman@users.noreply.github.com>
closes: #XXXX refs: #9322, #9299 #9443 ## Description PR #9322 is supposed to provide production quality support for asyncFlow guest functions to use `E`. It is being reviewed for that goal, and will not be merged until we think it meets that bar. However, we need to start integration testing of asyncFlow with orchestration, to spot mismatched assumptions we may have missed. For this purpose, we do not immediately need production quality `E` support. That is the purpose of this PR. It starts as a copy of the code from #9322 but need only be evaluated as adequate for these stopgap purposes before being merged. This PR does *NOT* claim to f-i-x #9299 , leaving that job to remain with #9322 Even though the requirements on this PR are so much lighter, reviewers should still look at the unresolved conversations on #9322 and determine if any of those need to first be solved even in this PR. ### Security Considerations When merging stopgap code to master, there is always the danger that it might be used as if it production code. We need to remember not to do so, instead waiting for #9322 to do the job for real. ### Scaling Considerations none ### Documentation Considerations just as this stopgap unblocks integration testing, it also likely unblocks documenting how to use asyncFlow, both in general and for orchestration. ### Testing Considerations As a stopgap, this PR does not need the rigorous testing that #9322 should have. ### Upgrade Considerations We need to not use this stopgap for production purposes.
Hi @mhofman , ok to reassign to you? |
See #9097 (comment)
makeGuestForHostVow
will need to create a handled promise whose handler reflects an invocation into a loggedcheckSend
, which is analogous tocheckCall
. But wherecheckCall
proceeds to do a synchronous host call,checkSend
needs to do a host eventual-send. An important design question is what the hander should do with the host promise for the result of the host eventual send, since it can only track host vows, not host promises.Likewise,
makeGuestForHostRemotable
will need to use the handled promise API to create the guest remotable as a remote presence. Unlike liveslot remote presences, this one can retain the same one methods that the currentmakeGuestForHostRemotable
gives it, if the host remotable is just a local far object with methods. These will still support synchronous guest-side calls. But a guest use ofE
to do an eventual send will bypass these guest-side methods and go directly to the appropriate promise handler which acts like the one described above.So the extra log opcode this will need is
checkSend
. The "return" side should already be well taken case of bydoFulfill
anddoReject
. Huh. ThedoFulfill
anddoReject
don't happen until the host promise is settled, so we'd only need to convert a settled host promise to a settled host vow for the log, which is not a problem. Whew! (@mhofman , you might have tried to explain it to me and I didn't get it until now.)The text was updated successfully, but these errors were encountered: