tower/util/boxed/
mod.rs

1//! Trait object [`Service`] instances
2//!
3//! Dynamically dispatched [`Service`] objects allow for erasing the underlying
4//! [`Service`] type and using the `Service` instances as opaque handles. This can
5//! be useful when the service instance cannot be explicitly named for whatever
6//! reason.
7//!
8//! There are two variants of service objects. [`BoxService`] requires both the
9//! service and the response future to be [`Send`]. These values can move freely
10//! across threads. [`UnsyncBoxService`] requires both the service and the
11//! response future to remain on the current thread. This is useful for
12//! representing services that are backed by [`Rc`] or other non-[`Send`] types.
13//!
14//! # Examples
15//!
16//! ```
17//! use futures_util::future::ready;
18//! # use tower_service::Service;
19//! # use tower::util::{BoxService, service_fn};
20//! // Respond to requests using a closure, but closures cannot be named...
21//! # pub fn main() {
22//! let svc = service_fn(|mut request: String| {
23//!     request.push_str(" response");
24//!     ready(Ok(request))
25//! });
26//!
27//! let service: BoxService<String, String, ()> = BoxService::new(svc);
28//! # drop(service);
29//! }
30//! ```
31//!
32//! [`Service`]: crate::Service
33//! [`Rc`]: std::rc::Rc
34
35mod layer;
36mod sync;
37mod unsync;
38
39#[allow(unreachable_pub)] // https://github.com/rust-lang/rust/issues/57411
40pub use self::{layer::BoxLayer, sync::BoxService, unsync::UnsyncBoxService};