Open jmaargh opened 2 years ago
Thanks for the feedback! I am well aware that the capnp-rpc has a lot of rough edges, and it does help to hear about your specific experiences.
- Am I doing anything wrong here? Obviously, this is an exceptionally simple example, so I know that this seeming to work doesn't necessarily validate the approach.
- I used async_io::block_on as the executor. I'm no expert, but this seemed to be among the simplest executors available for simple blocking usage (and I was already importing async_io for the Async trait anyways).
I don't see anything obviously wrong with your example code. I agree that it's annoying that you need to select()
on the RpcSystem
. Usually I end up spawning the RpcSystem
future on some separate task so that I don't need to worry about that. Does async_io
let you do that? Maybe it would be possible to use futures::executor::LocalPool
together with async_io
?
- Obviously, this was written quickly and a lot of best-practices are missing, but how careful do I need to be about tearing down RpcSystems nicely?
On a client, if all of the calls have completed, there's no harm in dropping the RpcSystem
.
On a server, dropping an RpcSystem
might interrupt some in-progress calls. Those clients would get a Disconnected
error.
Finally (and this may be better for a different issue), I don't understand why there isn't an option to generate a more idiomatic version of the Server trait? Is it just that it would be too much work?
What would your idiomatic version look like in the case where the method's return type a struct?
struct CountContext {
name @0 : String;
...
}
interface Counter {
count @0 () -> (count :UInt64, context: CountContext);
}
To make this feel like idiomatic Rust, I think we would need to figure out an automatic mapping between capnp types and Rust-native types. That would be very cool to have, but it would take a lot of work.
I don't see anything obviously wrong with your example code.
Great, thanks so much for looking over it.
I agree that it's annoying that you need to
select()
on theRpcSystem
. Usually I end up spawning theRpcSystem
future on some separate task so that I don't need to worry about that. Doesasync_io
let you do that? Maybe it would be possible to usefutures::executor::LocalPool
together withasync_io
?
It would definitely be possible to spawn a task, but I was trying to stay as far away from async as possible, ideally so that when any of the library functions return nothing else is left running, hence looking for the simplest possible blocking executor. Perhaps this isn't a sensible goal, but it was a goal I had in mind.
On a client, if all of the calls have completed, there's no harm in dropping the
RpcSystem
. On a server, dropping anRpcSystem
might interrupt some in-progress calls. Those clients would get aDisconnected
error.
Thanks, good to know. It would be great if this were added to doc comments
What would your idiomatic version look like in the case where the method's return type a struct?
struct CountContext { name @0 : String; ... } interface Counter { count @0 () -> (count :UInt64, context: CountContext); }
To make this feel like idiomatic Rust, I think we would need to figure out an automatic mapping between capnp types and Rust-native types. That would be very cool to have, but it would take a lot of work.
Yeah, I guess this is where the work would balloon somewhat. My first thought would be to generate rust struct
definitions for each capn proto struct
. Since all built-in types seem to have direct Rust equivalents, this should always be possible, the members are always going to be rust primitives, String
, Vec
, or another generated struct.
My first thought would be to generate rust struct definitions for each capn proto struct. Since all built-in types seem to have direct Rust equivalents, this should always be possible, the members are always going to be rust primitives, String, Vec, or another generated struct.
See #157 for some work in this direction.
I was just thinking about whether it would be possible to use Cap'n Proto RPC in a non-async application (in particular, I was interested in using unix domain sockets as transport). I've thrown together a simple example which I'd love to get your thoughts on: gist.
Observations:
VatNetwork
isAsyncRead
andAsyncWrite
objects, made the socket stuff surprisingly easy.RpcSystem
on the client side. I get the generatedClient
struct contains some handle back to theRpcSystem
so it can pass requests to it/receive responses from it. However, it would have been amazing to be able to get a future fromRpcSystem
which is "run until you've nothing to do", so I don't have toselect
with thepromise
.capnp_rpc
is surprisingly heavy in binary-size (4.5% 28.0% 209.5KiB capnp_rpc
fromcargo-bloat
for theserver
, for example), not problematically huge, just a little surprising.lib.rs
itself:5.0% 30.8% 233.9KiB cprpc_blocking
RpcSystem
actually do when polled? what does it mean to "bootstrap" it?). Generally, I find the API and naming very confusing (though I get that some of this is inherited from the upstream project). This is especially fraught because so much of the machinery is generated from the schema file.Specific questions:
async_io
for theAsync
trait anyways).RpcSystem
s nicely?Finally (and this may be better for a different issue), I don't understand why there isn't an option to generate a more idiomatic version of the
Server
trait? Is it just that it would be too much work? I'm thinking something that would look likerather than messing around with
Params
andResults
objects. My guess is that the answer is "you'd just be hiding the boilerplate and potentially doing unnecessary work", but surely it's much more common to want access to all params and results?