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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RPC] rref.get_type() should have default return type of future #51616

Open
rohan-varma opened this issue Feb 3, 2021 · 0 comments
Open

[RPC] rref.get_type() should have default return type of future #51616

rohan-varma opened this issue Feb 3, 2021 · 0 comments
Labels
module: rpc Related to RPC, distributed autograd, RRef, and distributed optimizer oncall: distributed Add this issue/PR to distributed oncall triage queue

Comments

@rohan-varma
Copy link
Member

rohan-varma commented Feb 3, 2021

馃殌 Feature

#50977 is adding an option to make rref.get_type() not block. Per @mrshenli 's comments on that PR, it would be better if the getRRefType and _rref_typeof_on_owner return a future by default, so this function always returns a future. Then we can chain additional logic as a callback.

Open question: If we make this API public, should it by only return a future, or should we have an option to also block and return an actual type (as is the current behavior?)

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @jjlilley @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu

@rohan-varma rohan-varma added the module: rpc Related to RPC, distributed autograd, RRef, and distributed optimizer label Feb 3, 2021
@facebook-github-bot facebook-github-bot added the oncall: distributed Add this issue/PR to distributed oncall triage queue label Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module: rpc Related to RPC, distributed autograd, RRef, and distributed optimizer oncall: distributed Add this issue/PR to distributed oncall triage queue
Projects
None yet
Development

No branches or pull requests

2 participants