1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82
// Library for concurrent I/O resource management using reactor pattern.
//
// SPDX-License-Identifier: Apache-2.0
//
// Written in 2021-2023 by
// Dr. Maxim Orlovsky <orlovsky@ubideco.org>
// Alexis Sellier <alexis@cloudhead.io>
//
// Copyright 2022-2023 UBIDECO Institute, Switzerland
// Copyright 2021 Alexis Sellier <alexis@cloudhead.io>
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
#![deny(
non_upper_case_globals,
non_camel_case_types,
non_snake_case,
unused_mut,
unused_imports,
dead_code,
missing_docs
)]
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
//! ### _Concurrent I/O without rust async problems_
//!
//! This repository provides a set of libraries for concurrent access to I/O resources (file,
//! network, devices etc) which uses reactor pattern with pluggable `poll` syscall engines. This
//! allows to handle situations like multiple network connections within the scope of a single
//! thread (see [C10k problem]).
//!
//! The crate can be used for building concurrent microservice architectures without polling all
//! APIs with `async`s.
//!
//! The reactor design pattern is an event handling pattern for handling service requests delivered
//! concurrently to a service handler by one or more inputs. The service handler then demultiplexes
//! the incoming requests and dispatches them synchronously to the associated request handlers[^1].
//!
//! Core concepts:
//! - **[`Resource`]**: any resource that can provide input to or consume output from the system.
//! - **[`Runtime`]**: runs an event loop to block on all resources. Sends the resource service when
//! it is possible to start a synchronous operation on a resource without blocking (Example: a
//! synchronous call to read() will block if there is no data to read.
//! - **Service**: custom business logic provided by the application for a given set of resources.
//! Service exposes a **[`Handler`] API** for the reactor [`Runtime`]. It is also responsible for
//! the creation and destruction of the resources.
//!
//! [`Reactor`] exposes a high-level API and manages multiple resources of two main kinds listeners
//! and sessions. It uses a dedicated thread blocked on I/O events from all of these resources and
//! than calls the [`Resource::handle_io`] to process the I/O and generate resource-specific event.
//!
//! Once a resource generates an event, reactor calls [`Handler`] API (in the context of the runtime
//! thread) to process each of the events.
//!
//! All resources under poll reactor must be representable as file descriptors.
//!
//! [C10k problem]: https://en.wikipedia.org/wiki/C10k_problem
//! [^1]: Schmidt, Douglas et al. Pattern-Oriented Software Architecture Volume 2: Patterns for
//! Concurrent and Networked Objects. Volume 2. Wiley, 2000.
#[macro_use]
extern crate amplify;
pub mod poller;
mod reactor;
mod resource;
mod timeouts;
pub use resource::{Io, Resource, ResourceId, WriteAtomic, WriteError};
pub use timeouts::{Timer, Timestamp};
pub use self::reactor::{Action, Controller, Error, Handler, Reactor, Runtime};