You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This actually implied Sized requirement since we have stored the response future as an enum unit tuple, which by itself requires Sized.
This means cannot just change the future type to impl Future (as you do with GAT futures), since this exactly is ?Sized (unsized) which is contradictory to the current design of tarpc.
We have to think forward for this. One possibility is to use microsoft/stackfuture. This gives us a Sized dyn future while we don't have to use Pin<Box<dyn Future<Output = T> + Send>> and thus implied the use of heap. I've created a helper for this, and it worked out alright:
The problem is this requires user interaction to specify the stack size, and if the heap size is too large (like if the system set a size to not go beyond a certain stack ulimit), they have to fallback using heap as well.
Otherwise, the best workaround for now is to either keep using boxed heap dyn future, or wait for Rust team to implement static async fn in dyn which I believe will take a year to finalize because of its unprecedented difficulty.
I took the stackfuture inspiration directly from Dyn async traits, part 9: call-site selection of the Baby Steps blog series, focused deeply on the topics of async fn ecosystem. Not sure if this would also throw us some more hint in the future but just saying.
The text was updated successfully, but these errors were encountered:
Hey, thanks for starting this discussion! I have an experimental branch that uses async fns in traits, please take a look and share any feedback: master...tikue:tarpc:master
Since Rust stablized GAT support back in early November, the follow up is of course static async fn.
However, the current design model of tarpc (or let's say the plugin/codegen) is based around storing RPC state within a Future itself:
tarpc/plugins/src/lib.rs
Lines 611 to 628 in 7e872ce
And then selecting it in the generated serve function:
tarpc/plugins/src/lib.rs
Lines 535 to 566 in 7e872ce
Although this increases flexibility so users can opt to use their own implementation of Future as shown in the readme example:
tarpc/tarpc/examples/readme.rs
Lines 25 to 34 in 7e872ce
This actually implied
Sized
requirement since we have stored the response future as an enum unit tuple, which by itself requiresSized
.This means cannot just change the future type to
impl Future
(as you do with GAT futures), since this exactly is?Sized
(unsized) which is contradictory to the current design of tarpc.We have to think forward for this. One possibility is to use microsoft/stackfuture. This gives us a
Sized
dyn future while we don't have to usePin<Box<dyn Future<Output = T> + Send>>
and thus implied the use of heap. I've created a helper for this, and it worked out alright:The problem is this requires user interaction to specify the stack size, and if the heap size is too large (like if the system set a size to not go beyond a certain stack ulimit), they have to fallback using heap as well.
Otherwise, the best workaround for now is to either keep using boxed heap dyn future, or wait for Rust team to implement static async fn in dyn which I believe will take a year to finalize because of its unprecedented difficulty.
I took the stackfuture inspiration directly from Dyn async traits, part 9: call-site selection of the Baby Steps blog series, focused deeply on the topics of async fn ecosystem. Not sure if this would also throw us some more hint in the future but just saying.
The text was updated successfully, but these errors were encountered: