Flow-IPC 1.0.2
Flow-IPC project: Public API.
Class List
Here are the classes, structs, unions and interfaces with brief descriptions:
[detail level 123456]
 Nboost
 NsystemSmall group of miscellaneous utilities to ease work with boost.system, joining its boost::system namespace
 Cis_error_code_enum<::ipc::session::error::Code >Ummm – it specializes this struct to – look – the end result is boost.system uses this as authorization to make enum Code convertible to Error_code
 Cis_error_code_enum<::ipc::session::shm::arena_lend::jemalloc::error::Code >Ummm – it specializes this struct to – look – the end result is boost.system uses this as authorization to make enum Code convertible to Error_code
 Cis_error_code_enum<::ipc::shm::classic::error::Code >Ummm – it specializes this struct to – look – the end result is boost.system uses this as authorization to make enum Code convertible to Error_code
 Cis_error_code_enum<::ipc::transport::error::Code >Ummm – it specializes this struct to – look – the end result is boost.system uses this as authorization to make enum Code convertible to Error_code
 Cis_error_code_enum<::ipc::transport::struc::error::Code >Ummm – it specializes this struct to – look – the end result is boost.system uses this as authorization to make enum Code convertible to Error_code
 Cis_error_code_enum<::ipc::transport::struc::shm::error::Code >Ummm – it specializes this struct to – look – the end result is boost.system uses this as authorization to make enum Code convertible to Error_code
 NipcCatch-all namespace for the Flow-IPC project: A library/API in modern C++17 providing high-performance communication between processes
 NsessionFlow-IPC module providing the broad lifecycle and shared-resource organization – via the session concept – in such a way as to make it possible for a given pair of processes A and B to set up ipc::transport structured- or unstructured-message channels for general IPC, as well as to share data in SHared Memory (SHM)
 NshmIpc::session sub-namespace that groups together facilities for SHM-backed sessions, particularly augmenting Client_session, Server_session, and Session_server classes by providing SHM-backed zero-copy functionality
 Narena_lendBundles ipc::session::shm support for the various arena-lend-style SHM-providers, as of this writing at least ipc::session::shm::arena_lend::jemalloc
 NclassicSupport for SHM-backed ipc::session sessions and session-servers with the SHM-classic (ipc::shm::classic::Pool_arena) provider
 CArena_to_shm_sessionImplementation of Arena_to_shm_session_t
 CArena_to_shm_session< ipc::shm::arena_lend::jemalloc::Ipc_arena >Implementation of Arena_to_shm_session_t for SHM-jemalloc arenas
 CArena_to_shm_session< ipc::shm::classic::Pool_arena >Implementation of Arena_to_shm_session_t for SHM-classic arenas
 Nsync_iosync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::session
 CClient_session_adaptersync_io-pattern counterpart to async-I/O-pattern session::Client_session types and all their SHM-aware variations (at least shm::classic::Client_session et al and shm::arena_lend::jemalloc::Client_session et al)
 CServer_session_adaptersync_io-pattern counterpart to async-I/O-pattern session::Server_session types and all their SHM-aware variations (at least shm::classic::Server_session et al and shm::arena_lend::jemalloc::Server_session et al)
 CSession_server_adaptersync_io-pattern counterpart to async-I/O-pattern session::Session_server types and all their SHM-aware variations (at least shm::classic::Session_server and shm::arena_lend::jemalloc::Session_server)
 CAppA description of an application in this ipc::session inter-process communication universe
 CClient_appAn App that is used as a client in at least one client-server IPC split
 CClient_session_mvImplements Session concept on the Client_app end: a Session_mv that first achieves PEER state by connecting to an opposing Session_server_mv via Client_session_mv::sync_connect()
 CServer_appAn App that is used as a server in at least one client-server IPC split
 CServer_session_mvImplements Session concept on the Server_app end: a Session that is emitted in almost-PEER state by local Session_server accepting a connection by an opposing Client_session_mv::sync_connect()
 CSessionA documentation-only concept defining the local side of an IPC conversation (session) with another entity (typically a separate process), also represented by a Session-implementing object, through which one can easily open IPC channels (ipc::transport::Channel), among other IPC features
 CSession_mvImplements the Session concept when it is in PEER state
 CSession_serverTo be instantiated typically once in a given process, an object of this type asynchronously listens for Client_app processes each of which wishes to establish a session with this server process; emits resulting Server_session objects locally
 NshmModules for SHared Memory (SHM) support
 NclassicIpc::shm sub-module with the SHM-classic SHM-provider. See ipc::shm doc header for introduction
 CPool_arenaA SHM-classic interface around a single SHM pool with allocation-algorithm services by boost.interprocess, as in bipc::managed_shared_memory, with symmetric read/write semantics, compatible with ipc::shm::stl STL-compliance and SHM-handle borrowing manually or via ipc::session
 NstlIpc::shm sub-module providing integration between STL-compliant components (including containers) and SHared Memory (SHM) providers
 CArena_activatorRAII-style class operating a stack-like notion of a the given thread's currently active SHM-aware Arena, so that Stateless_allocator knows which Arena is currently active w/r/t a given code context operating on a SHM-stored container instance
 CStateless_allocatorStateless allocator usable with STL-compliant containers to store (or merely read) them directly in SHM in a given SHM-aware Arena
 CArena_to_borrower_allocator_arenaImplementation of Arena_to_borrower_allocator_arena_t
 CArena_to_borrower_allocator_arena< classic::Pool_arena >Implementation of Arena_to_borrower_allocator_arena_t for SHM-classic arenas
 NtransportFlow-IPC module providing transmission of structured messages and/or low-level blobs (and more) between pairs of processes
 Nasio_local_stream_socketAdditional (versus boost.asio) APIs for advanced work with local stream (Unix domain) sockets including transmission of native handles through such streams; and peer process credentials acquisition
 COpt_peer_process_credentialsGettable (read-only) socket option for use with asio_local_stream_socket::Peer_socket .get_option() in order to get the connected opposing peer process's credentials (PID/UID/GID/etc.)
 NstrucSub-module of Flow-IPC module ipc::transport providing transmission of structured messages specifically
 NshmSegregates zero-copy/SHM implementations of concepts residing in parent namespace ipc::transport::struc proper – most notably the concepts ipc::transport::struc::Struct_builder and ipc::transport::struc::Struct_reader – and items related to them
 Nsync_iosync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::transport::struc
 CChannelOwning and wrapping a pre-connected transport::Channel peer (an endpoint of an established channel over which unstructured messages and optionally native handles can be transported), this template is the central pillar of the ipc::transport::struc (structured layer), capable of communicating structured capnp-schema-based messages (and native handles)
 CChannel_baseChannel base that contains non-parameterized public items such as tag types and constants
 CHeap_fixed_builderImplements Struct_builder concept by straightforwardly allocating fixed-size segments on-demand in the regular heap and serializing directly inside those segments
 CHeap_fixed_builder_capnp_message_builderA capnp::MessageBuilder used by Heap_fixed_builder: similar to a capnp::MallocMessageBuilder with the FIXED_SIZE alloc-strategy but with framing space around the allocated segment(s)
 CHeap_readerImplements Struct_reader concept by straightforwardly interpreting a serialization by Heap_fixed_builder or any other builder that produces segments directly readable via SegmentArrayMessageReader
 CMsg_inA structured in-message instance suitable as received and emittable (to user) by struc::Channel
 CMsg_outA structured out-message suitable to be sent via struc::Channel::send() (et al)
 CNull_sessionValue for Struct_builder::Session when no extra information is needed when serializing Struct_builder for subsequent sending to another process
 CStruct_builderA documentation-only concept defining the behavior of an object capable of zero-copy-serializing, similar to capnp::MessageBuilder but geared to transmission over pipe-like IPC transports
 CStruct_readerA documentation-only concept that is, conceptually, roughly what capnp::MessageReader is to capnp::MessageBuilder, to be used on an in-message serialized by a counterpart Struct_builder, having been transmitted over an IPC transmitter of blobs
 Nsync_iosync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::transport
 CBlob_receiverA documentation-only concept: what transport::Blob_receiver is to transport::Native_handle_receiver (namely a degenerate version thereof), this is to sync_io::Native_handle_receiver
 CBlob_senderA documentation-only concept: what transport::Blob_sender is to transport::Native_handle_sender (namely a degenerate version thereof), this is to sync_io::Native_handle_sender
 CBlob_stream_mq_receiverImplements sync_io::Blob_receiver concept by using an adopted Persistent_mq_handle MQ handle to an MQ (message queue) of that type, such as a POSIX or bipc MQ
 CBlob_stream_mq_senderImplements sync_io::Blob_sender concept by using an adopted Persistent_mq_handle MQ handle to an MQ (message queue) of that type, such as a POSIX or bipc MQ
 CNative_handle_receiverA documentation-only concept defining the behavior of an object that is the sync_io-pattern counterpart of the async-I/O-pattern-following concept of the same name in our parent namespace: transport::Native_handle_receiver
 CNative_handle_senderA documentation-only concept defining the behavior of an object that is the sync_io-pattern counterpart of the async-I/O-pattern-following concept of the same name in our parent namespace: transport::Native_handle_sender
 CNative_socket_streamImplements both sync_io::Native_handle_sender and sync_io::Native_handle_receiver concepts by using a stream-oriented Unix domain socket, allowing high-performance but non-zero-copy transmission of discrete messages, each containing a native handle, a binary blob, or both
 CNative_socket_stream_acceptorsync_io-pattern counterpart to async-I/O-pattern transport::Native_socket_stream_acceptor
 CBipc_mq_handleImplements the Persistent_mq_handle concept by thinly wrapping bipc::message_queue, which is boost.interprocess's persistent message queue API
 CBlob_receiverA documentation-only concept defining the behavior of an object capable of reliably/in-order receiving of discrete messages, each containing a binary blob
 CBlob_senderA documentation-only concept defining the behavior of an object capable of reliably/in-order sending of discrete messages, each containing a binary blob
 CBlob_stream_mq_baseBase of Blob_stream_mq_sender and Blob_stream_mq_receiver containing certain static facilities, particularly for post-abort persistent resource cleanup
 CBlob_stream_mq_receiverImplements Blob_receiver concept by using an adopted Persistent_mq_handle MQ handle to an MQ (message queue) of that type, such as a POSIX or bipc MQ
 CBlob_stream_mq_senderImplements Blob_sender concept by using an adopted Persistent_mq_handle MQ handle to an MQ (message queue) of that type, such as a POSIX or bipc MQ
 CChannelPeer to a bundle of 1-2 full-duplex pipe(s), one for transmitting unstructured binary blobs; the other for transmitting native handle+blob combos; hence a Blob_sender + Blob_receiver, a Native_handle_sender + Native_handle_receiver, or both
 CMqs_channelA Channel with at least a blobs pipe consisting of two MQs of type Persistent_mq_handle (template arg 1); and possibly a handles pipe as governed by template args 2 and 3 which default to Null_peer (in which case the handles pipe is disabled)
 CMqs_socket_stream_channelA Channel with a blobs pipe consisting of 2 MQs of type Persistent_mq_handle (template arg); and a handles pipe over a Unix domain socket connection
 CNative_handle_receiverA documentation-only concept defining the behavior of an object capable of reliably/in-order receiving of discrete messages, each containing a native handle, a binary blob, or both
 CNative_handle_senderA documentation-only concept defining the behavior of an object capable of reliably/in-order sending of discrete messages, each containing a native handle, a binary blob, or both
 CNative_socket_streamImplements both Native_handle_sender and Native_handle_receiver concepts by using a stream-oriented Unix domain socket, allowing high-performance but non-zero-copy transmission of discrete messages, each containing a native handle, a binary blob, or both
 CNative_socket_stream_acceptorA server object that binds to a Shared_name and listens for incoming Native_socket_stream connect attempts to that name; and yields connected-peer sync_io::Native_socket_stream objects, one per counterpart opposing *_connect()
 CNull_peerDummy type for use as a template param to Channel when either the blobs pipe or handles pipe is disabled; as well as to mark a given peer object as not having a counterpart form: a sync_io object shall have its using Sync_io_obj = Null_peer and coversely for async-I/O guys and their Async_io_objs
 CPersistent_mq_handleA documentation-only concept defining the behavior of an object representing a light-weight handle to a message queue, capable of receiving/sending discrete messages in non-blocking/blocking/timed-blocking fashion, as well as some support for polling/waiting and interruptions thereof
 CPosix_mq_handleImplements the Persistent_mq_handle concept by wrapping the POSIX message queue API (see man mq_overview)
 CProtocol_negotiatorA simple state machine that, assuming the opposide side of a comm pathway uses an equivalent state machine, helps negotiate the protocol version to speak over that pathway, given each side being capable of speaking a range of protocol versions and reporting the highest such version to the other side
 CSocket_stream_channelA Channel with a handles pipe only (no blobs pipe) that uses a Unix domain socket connection as the underlying transport for that pipe
 CSocket_stream_channel_of_blobsA Channel with a blobs pipe only (no handles pipe) that uses a Unix domain socket connection as the underlying transport for that pipe
 NutilFlow-IPC module containing miscellaneous general-use facilities that ubiquitously used by ~all Flow-IPC modules and/or do not fit into any other Flow-IPC module
 Nsync_ioContains common code, as well as important explanatory documentation in the following text, for the sync_io pattern used in ipc::transport and ipc::session to provide fine-tuned control over integrating asynchronous Flow-IPC activities into the user's event loop
 CAsio_waitable_native_handleUseful if using the sync_io pattern within a user event loop built on boost.asio (optionally with flow.async help), an object of this class wraps a non-null Native_handle and allows one to use .async_wait() to perform event waiting on behalf of any sync_io-implementing ipc::transport or ipc::session object
 CDefault_init_allocatorAllocator adaptor (useful for, e.g., vector that skips zero-filling) that turns a value-initialization T() into a default-initialization for those types, namely PoDs, for which default-initialization is a no-op
 CNative_handleA monolayer-thin wrapper around a native handle, a/k/a descriptor a/k/a FD
 CProcess_credentialsA process's credentials (PID, UID, GID as of this writing)
 CShared_nameString-wrapping abstraction representing a name uniquely distinguishing a kernel-persistent entity from all others in the system, or a fragment of such a name
 CUse_counted_objectSimple counter that manually tracks utilization. It is not thread-safe