Skip to content
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

General mechanism for synchronous access #518

Closed
michaelfig opened this issue Feb 6, 2020 · 9 comments · Fixed by #525
Closed

General mechanism for synchronous access #518

michaelfig opened this issue Feb 6, 2020 · 9 comments · Fixed by #525
Labels
eventual-send package: eventual-send

Comments

@michaelfig
Copy link
Member

This makes unwrap(foo) useful when foo is not a Promise at all.

@michaelfig michaelfig added the eventual-send package: eventual-send label Feb 6, 2020
@michaelfig
Copy link
Member Author

michaelfig commented Feb 6, 2020

@katelynsills the code I'm thinking of is:

function sync(value) {
  if (!value || !value.then) {
   // Not a Thenable.  So, we can access it synchronously.
   return value;
  }
  // Try unwrapping the promise.
  return HandledPromise.unwrap(value);
}

function foo(resultP) {
  const result = sync(resultP);
  // result should be defined if resultP can be obtained synchronously
}

@michaelfig michaelfig changed the title HandledPromise.unwrap: throw only on Promises that aren't resolved HandledPromises General mechanism for synchronous access Feb 6, 2020
@katelynsills
Copy link
Contributor

I like this a lot. I'm wondering about the sync name though, it sounds like synchronizing rather getting a local object potentially from a promise synchronously. I'm not sure it's much better, but what about getLocal or something like that?

@michaelfig
Copy link
Member Author

Yes, getLocal sounds reasonable. The test doesn't have to be very elaborate because we assume you're only dealing with objects that are already local, or have been passed to you through a secure comms system from another vat.

@katelynsills
Copy link
Contributor

Ok, sounds good to me!

@erights
Copy link
Member

erights commented Feb 6, 2020

Are we talking about two operations rather than one, or are we just talking about the name of the one operation? I think I'm missing some context.

I think we only need one operation, that should always return a non-promise non-thenable immediately.

@katelynsills
Copy link
Contributor

I think @michaelfig is saying that E.unwrap() needs to remain as is, but I can make my own helper function getLocal. Is that right?

@erights
Copy link
Member

erights commented Feb 7, 2020

@michaelfig does E.unwrap() throwing on non-promises serve any purpose?

@michaelfig
Copy link
Member Author

@erights No particular purpose. Shall we change E.unwrap() as described above?

@erights
Copy link
Member

erights commented Feb 7, 2020

Yes, thanks!

michaelfig added a commit that referenced this issue Feb 7, 2020
Closes #518

This makes unwrap a lot more useful in the case when the
calling code may or may not be in a different vat than the supplied
argument.
michaelfig added a commit that referenced this issue Feb 7, 2020
Closes #518

This makes unwrap a lot more useful in the case when the
calling code may or may not be in a different vat than the supplied
argument.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
eventual-send package: eventual-send
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants