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 //! # extern crate futures; 18 //! # extern crate tower_service; 19 //! # extern crate tower_util; 20 //! # use futures::*; 21 //! # use futures::future::FutureResult; 22 //! # use tower_service::Service; 23 //! # use tower_util::{BoxService, service_fn}; 24 //! // Respond to requests using a closure, but closures cannot be named... 25 //! # pub fn main() { 26 //! let svc = service_fn(|mut request: String| { 27 //! request.push_str(" response"); 28 //! Ok(request) 29 //! }); 30 //! 31 //! let service: BoxService<String, String, ()> = BoxService::new(svc); 32 //! # drop(service); 33 //! } 34 //! ``` 35 36 mod sync; 37 mod unsync; 38 39 pub use self::{sync::BoxService, unsync::UnsyncBoxService}; 40