* Create a directory for the `future::server` module, which has become quite large. server.rs => server/mod.rs. Server submodules for shutdown and connection logic are added.
* Add fn thread_pool(...) to sync::server::Options
* Configure idle threads to expire after one minute
* Add tarpc::util::lazy for lazily executing functions. Similar to `futures::lazy` but useful in different circumstances. Specifically, `futures::lazy` typically requires a closure, whereas `util::lazy` kind of deconstructs a closure into its function and args.
* Remove some unstable features, and `cfg(plugin)` only in tests. Features `unboxed_closures` and `fn_traits` are removed by replacing manual Fn impls with Stream impls. This actually leads to slightly more performant code, as well, because some `Rc`s could be removed.
* Fix tokio deprecation warnings. Update to use tokio-io in lieu of deprecated tokio-core items. impl AsyncRead's optional `unsafe fn prepare_uninitialized_buffer` for huge perf wins
* Add debug impls to all public items and add `deny(missing_debug_implementations)` to the crate.
* Bump tokio core version.
The merge of rust-lang/rust#40043 removes parse_ty_path in the latest
nightly, which we depended on. This patch rewrites that code path using
parse_path, and in the process eliminates an unreachable!() if let arm.
0 is a sentinel value used to make all enums refutable. This is a hack around issues in maros
where you're unknowingly treating irrefutable patterns as refutable, which is unfortunately
a hard error.
The server panics if it ever encountered the 0-variant, which before this patch was possible. Now,
it's not possible, because 0-variants are now not able to be deserialized.
Since rust-lang/rust#40346 has now been merged, Attribute no longer has
a .value field. Instead, we must follow the token stream and modify the
tokens directly. For Docstring attributes, there should only be one
token, the docstring value.
Unfortunately, cargo's semantic versioning gets confused by the
"-alpha" suffix in current bincode versions (I think): even though
tarpc's Cargo.toml specified version "1.0.0-alpha4", cargo will
download the more recent "1.0.0-alpha6", which has breaking changes
to the `SizeLimit` enum.
This change makes tarpc work with bincode 1.0.0-alpha6 and updates the
dependency.
* Change `client::{future, sync}, server::{future, sync}` to `future::{client, server}, sync::{client, server}`
This reflects the most common usage pattern and allows for some types to not need to be fully qualified when used together (e.g. the previously-named `client::future::Options` and `server::future::Options` can now be `client::Options` and `server::Options`).
* sync::client: create a RequestHandler struct to encapsulate logic of processing client requests.
The largest benefit is that unit testing becomes easier, e.g. testing that the request processing stops when all request senders are dropped.
* Rename Serialize error variants to make sense.
* Rename tarpc_service_ConnectFuture__ => Connect (because it's public)
* Use tokio proto's ClientProxy.
Rather than reimplement the same logic. Curiously, this commit
isn't a net loss in LOC. Oh well.
* Factor out os-specific functionality in listener() into their own fns
* Remove service-fn dep
The basic strategy is to start a reactor on a dedicated thread running a request stream.
Requests are spawned onto the reactor, allowing multiple requests to be
processed concurrently. For example, if you clone the client to make requests
from multiple threads, they won't have to wait for each others'
requests to complete before theirs start being sent out.
Also, client rpcs only take &self now, which was also required for
clients to be usable in a service.
Also added a test to prevent regressions.
* Add server::Handle::shutdown
* Hybrid approach: lameduck + total shutdown when all clients disconnect.
* The future handle has addr() and shutdown(), but not run().
* Return a concrete type from `server::listen`.
* Change `FutureServiceExt::listen` to return `(SocketAddr, Listen)`, where `Listen` is a struct created by the `service!` macro that `impls Future<Item=(), Error=()>` and represents server execution.
* Disable `conservative_impl_trait` as it's no longer used.
* Update `FutureServiceExt` doc comment.
* Update `SyncServiceExt` doc comment. Also annotate `server::Handle` with `#[must_use]`.
* `cargo fmt`
* Make a reactor handle mandatory for server.
This removes the Send bound from FutureService. The Send bound
is still required for SyncService, since clones are sent to
new threads for each request. (This is more fodder for the argument
that there should be a distinct Options struct for each combination of
async/sync and client/server.)
This commit also makes FutureService::listen return an io::Result
rather than a Future; the future was never really necessary and
had the unintended consequence of making SyncService::listen
deadlock when the options specified a handle (because that means
the reactor driving the service lives on the same thread that
SyncService is waiting on).
`SyncClient` is no longer `Clone` because it needs to create
a new `reactor::Core` when cloning. Tokio Clients are `Clone` but
they don't allow moving the cloned client onto a new reactor.
* Change pubsub to use Rc<Refcell<>> instead of Arc<Mutex<>>.
This is possible since services no longer need to be Send.
* Remove some unnecessary unstable features.
There 3 remaining unstable features. The hardest to remove is plugin, because
we rely on compiler plugins to rewrite types from snake case to camel. It's
possible this can be removed before the proc macros rewrite lands if
impl Trait is extended to work with traits.
* Clean up example
* Sync servers now spawn a reactor on a thread. It's decided that
sync users should not have to know about tokio at all.
* Don't allow specifying a reactor::Core on client options.
* Fail fast in server::listen if local_addr() returns Err.
It's strictly more flexible, because everything that impls Future impls IntoFuture, and it
additionally allows returning types like Result. Which is nice.
* feat(serde): upgrade serde to 0.9
If you are using `#[derive(Serialize, Deserialize)]` or implementing
your own (de)serialization behavior for your RPC types you will need to
ensure you are using serde 0.9.x.
[breaking-change]
* chore(byteorder): upgrade byteorder to 1.0
This allows the client to drive its own execution, as one would expect.
Previously, the reactor had to be driven on a separate thread, which was confusing.
This has a couple notable side effects:
1. SyncClient is no longer `Clone`. This is because `reactor::Core`
is not `Clone`, and creating one is not infallible
(`Core::new` returns a `Result`).
2. SyncClient does not use the user-specified `client::Options::handle` or
`client::Options::remote`, because it constructs its own reactor.
When `-- features tls` is specified for tarpc, RPC communication can
also occur over a `TlsStream<TcpStream>` instead of a `TcpStream`.
* The functional tests have been refactored to use a common set of
functions for constructing the client and server structs so that all
the tests are shared across non-tls and tls test runs.
* Update pre-push to test TLS
* The `cfg_attr` logic caused many false warnings from clippy, so for now the crate docs for TLS are not tested.
Some future-returning fns implicitly require the presence of an execution task. Wrapping in a lazy future ensures that by the time the future is polled, there is a task present.