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
With this commit changes how we generate the `Server` traits for
interfaces. We now generate `async fn` compatible traits instead
of methods returning `Promise`.
The methods now receive `&self` instead of `&mut self`, which
causes server implementations to need `RefCell`/`Cell` for mutable
state, similar to what we have for `Send` servers in other RPC systems.
This is slightly different from what was discussed in #577, because
we don't actually have a `Rc<impl Server>` inside `Client`, but instead
`Rc<ServerDispatch>`, making the receiver a `Rc<Self>` (which would
allow easier background processing spawning) would require an extra
allocation, pointer chasing, and ref-counting operations.
From the changes in the examples, we can see that the code is
significantly easier to understand, and `pry!` is almost never
needed. The only case I truly needed to use it was when the code
needed to manually create `Promise` due to a `RefMut` preventing
use to use `async fn` (which could cause double borrows).
In matters of breaking changes, this of course breaks every pre-existing
implementation, but it should be an easy migration. In the crates
themselves, `capnp::capability::Server` needed to be changed to receive
`Rc<Self>` instead of `&mut self`, not only the `&mut` isn't necessary
anymore but also receiving a `Rc<Self>` (which we already have where it
is called) also allow us to make the generated methods for `Server` traits
non-'static, which makes the `async fn` syntax significantly more
useful. Also, some methods in `CapabilityServerSet` which exposed the
internal `Rc<RefCell<Dispatcher>>` from `Client` needed to be changed
to return just `Rc<Dispatcher>`.
Also, given that we're using `async/await` in the generated code, they
can't be compiled in editions 2015/2018 anymore. It may be possible to
support them with some added complexity in the generated code, but I
don't think it is worth it.
Closes: #577
0 commit comments