stl_fwd.hpp

Go to the documentation of this file.

/* Flow-IPC: Shared Memory
 * Copyright 2023 Akamai Technologies, Inc.
 *
 * 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
 *
 *   https://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. */
 
/// @file
#pragma once
 
#include <boost/move/traits.hpp>
 
/**
 * ipc::shm sub-module providing integration between STL-compliant components (including containers)
 * and SHared Memory (SHM) providers.
 *
 * @see The guided Manual chapter @ref transport_shm covers this topic in use.
 *
 * @note This sub-module/namespace is not limited to working with the jemalloc-based SHM
 *       provider supplied elsewhere in ipc::shm; it can and does work with any other SHM-provider
 *       capable of allocating an uninitialized buffer in SHM and later manually deallocating it by raw pointer.
 *       In fact, due to its simplicity of setup, the SHM-classic (a/k/a boost.interprocess) SHM-provider
 *       (in ipc::shm::classic) may be used in comments as the go-to example.
 *
 * ### Background ###
 * What's this trying to do?  Answer: It's quite a narrow purpose in fact, and it's important to separate it
 * from orthogonal concerns to avoid confusion.  So let's slowly explain step by step.  Suppose we define as
 * a bare-bones SHM-provider via an `Arena` concept, where `Arena` is a class -- instantiated in some unspecified
 * way -- with at least these key methods:
 *
 *   ~~~
 *   class Arena
 *   {
 *   public:
 *     // Allocate uninitialized buffer of n bytes in this SHM arena; return locally-dereferenceable pointer
 *     // to that buffer.  Throw exception if ran out of resources.  (Some providers try hard to avoid this by
 *     // internally mapping more SHM pools, a/k/a mmap()ped areas, as needed.  However it is OK to throw:
 *     // e.g., an STL container might throw when trying to allocate something; such is life.)  Do not return
 *     // null.
 *     void* allocate(size_t n);
 *
 *     // Undo allocate() that returned `p`; or the equivalent operation if the SHM-provider allows
 *     // process 2 to deallocate something that was allocated by process 1 (and `p` indeed was allocated
 *     // in a different process but transmitted to the current process; and was properly made
 *     // locally-dereferenceable).
 *     void deallocate(void* p);
 *   }
 *   ~~~
 *
 * Suppose you have a plain-old-datatype (POD) type `T`; like an `int` or a `struct` with a bunch of scalars
 * or arrays of scalars or various combos like that.  To create a `T` in SHM, one could just call
 * `Arena::allocate(sizeof(T))` and load it up with values based off the returned pointer, having
 * cast it to `T*`.  (Or one could use placement-construction but never mind.)  To destroy it, one
 * would `Arena::deallocate()` passing-in the returned pointer from `allocate()`.  To transmit to
 * another process, one would need to somehow send over a representation of `T* p`, then make it
 * locally-dereferenceable, if the SHM-mapped vaddrs are not synced between the 2 processes.
 *
 * Everything in the preceding paragraph is 100% orthogonal to ipc::shm::stl.  That is not our problem.
 * Now suppose `T` is not a POD but a bit more complex.  Let's say it's `Vector<E>`, similar to `vector<E>`,
 * with the usual semantics.  Its internal representation would be very similar to:
 *
 *   ~~~
 *   template<typename E> class Vector
 *   {
 *   private:
 *     // Currently allocated buffer starts at m_buf, is `m_buf_sz * sizeof(E)` long; and the used
 *     // range (within [0, size())) starts at m_buf also but is only m_elem_ct (<= m_buf_sz) `E`s long.
 *     E* m_buf; size_t m_buf_sz; size_t m_elem_ct;
 *   }
 *   using T = Vector<int>;
 *   ~~~
 *
 * Allocating a `T` itself works the same as before; but that would only allocate the outer layer -- `sizeof(T)`
 * -- with those 3 data members themselves.  But what happens when the `Vector` allocates into `m_buf`?
 * A naive impl would just use `new`.  But that wouldn't work if one tried to access the `T` in another process,
 * even having acquired a locally-dereferenceable pointer to it (which is outside our scope completely; but
 * doable as we established earlier): `m_buf` is never locally-dereferenceable in any process but the original
 * one.  One would have to somehow translate it and change `m_buf` to make it locally-dereferenceable; but then
 * it would become wrong in the original process: remember that the idea is to place the `T` *itself* into SHM
 * in the first place.  One could write internal `Vector` code that would do the translation -- essentially be
 * specifically SHM-aware -- but that's terribly onerous a requirement for a container.
 *
 * The good news is the STL containers, at least per standard and at least the `boost::container` impls of them,
 * use a technique called *allocators* that resolves this problem (among others).  So now consider `vector<E>`,
 * namely an STL-standard-compliant implementation like `boost::container::vector` (and possibly your built-in
 * `std::vector`, though that may or may not be fully STL-standard-compliant ironically).  What it does
 * essentially is:
 *
 *   ~~~
 *   template<typename E, typename Allocator = std::allocator<E>> class Vector
 *   {
 *   private:
 *     Allocator m_alloc; // Usually initialized via default-ct `Allocator()` at ctor time.
 *
 *     // Currently allocated buffer starts at m_buf, is `m_buf_sz * sizeof(E)` long; and the used
 *     // range (within [0, size())) starts at m_buf also but is only m_elem_ct (<= m_buf_sz) `E`s long.
 *     Allocator::pointer m_buf; size_t m_buf_sz; size_t m_elem_ct;
 *   }
 *   using T = Vector<int>;
 *   ~~~
 *
 * Firstly note the type of `m_buf`: it uses not a raw pointer but an allocator-type-driven type which must
 * have certain pointer-like semantics.  In `std::allocator`, it *is* simply the raw pointer `E*` after all;
 * but for SHM we need to provide something else.  Secondly when it needs to allocate `m_buf`, it no longer
 * does `new`.  Instead it does basically `m_buf = m_alloc.allocate(m_buf_sz)`.  Conversely when deleting
 * instead of `delete` it does `m_alloc.deallocate(m_buf, m_buf_sz)`.
 *
 * So via the allocator's (1) alloc/dealloc methods and (2) its mandated pointer type, the allocation strategy *and*
 * pointer storage can be parameterized.  As for `m_alloc` itself, it is often (usually) an empty object
 * (`is_empty_v<Allocator> == true`; with the empty-base optimization it takes no space in the container); that's
 * a *stateless* allocator; and it is always default-cted.  It can also be stateful (in which case it must be
 * explicitly constructed).  In real `vector` you'll see support for both.
 *
 * How does this help our SHM use case?  Firstly, of course, `allocate()` and `deallocate()` can be written to
 * allocate/deallocate via `Arena::[de]allocate()`.  Secondly, the `pointer` type can be something
 * that, when stored in SHM, contains bits sufficient for its own methods, such as the dereference operator,
 * compute the locally-dereferenceable location `void*` just from those bits, regardless of which process it's in.
 * So in the case of SHM-classic, for example, `pointer` would be internally `bipc::offset_ptr<E>`, which uses a
 * clever technique, namely storing inside the `offset_ptr` the offset compared to its own `this`.  Remember
 * this would be inside the same SHM pool, which is how the `classic` Arena works (it operates within one SHM pool).
 *
 * Now: the *outside* allocation of `T` (`Vector<E>`) itself is done directly by the SHM `Arena` user.
 * Once the STL-compliant container is involved, it does it indirectly via its `Allocator`.  The same holds of
 * deallocation: *outside* deallocation would invoke the `T::~T()` dtor first, which would then deallocate
 * via `Allocator::deallocate()`; and then `Arena::deallocate()` the raw buffer (`sizeof(T)` long).
 *
 * If `T` needs to allocate more objects that do yet more allocation on its behalf, then it would remember to
 * propagate the `Allocator` to those, indefinitely.  These *inside* allocations/deallocations/dereferencing
 * all happen via `Allocator`.  One must only worry about invoking the ctor or dtor of `T` within the
 * process that is indeed allowed to allocate/deallocate.  (So if `Arena` does support deallocation in
 * not-the-original-allocating process, then the dtor could be called in any process working with the *outside* `T`.
 * If not, then not.)
 *
 * ### The task ###
 * So that's the background.  The main product of this namespace ipc::shm::stl is SHM-aware allocator types that
 * can be used as template params to STL-compliant containers (and other types at times) in order to be able
 * to allocate nested containers-of-containers...-of-PODs-of-... directly in SHM in such a way as to be accessible
 * in multiple processes, as long as the *outside* `T*` is properly transmitted from process to process by the user.
 * Only the *outside* SHM handle to the container-of-... is something the user worries about; the rest "just works,"
 * as long as all containers involved are properly parameterized to use the SHM-aware allocator types we provide.
 *
 * The main product, then, is Stateless_allocator.  See its doc header.  The short version for your convenience:
 *   - Stateless_allocator is itself parameterized on `Arena`, which must be a SHM-allocating type like the one used
 *     above.  `Arena` must(^) supply: `allocate()`, `deallocate()`, and `Pointer`.  The `Pointer` must
 *     be a *fancy pointer* type that can produce a locally-dereferenceable `void*` and has data member(s)
 *     that contain bits that are process-agnostic (such as an offset, or pool ID and offset, and so on) when
 *     stored in SHM.
 *     - In particular, classic::Pool_arena complies with these requirements.  Its allocate/deallocate work within 1
 *       SHM pool per Arena.  Its `Pointer` is internally `bipc::offset_ptr`.
 *     - (^) There is, for SHM-arena-lending providers (e.g.: SHM-jemalloc, centered on
 *       arena_lend::jemalloc::Ipc_arena), a key case where `Arena` must merely supply `Pointer`, not allocate() or
 *       deallocate().  See "Use in read-only borrowing mode" in Stateless_allocator doc header.
 *   - Stateless_allocator is stateless.  It is always default-cted, so all the user must do is remember to
 *     provide Stateless_allocator as the allocator template param(s) to the container type(s) involved.
 *     Therefore it must know on which `Arena` it shall operate.  This is controlled on a thread-local basis
 *     via RAII-style helper `Arena_activator`.  (So the user must use `Arena_activator ctx{Arena*}` to
 *     activate the "current" `Arena` for the purposes of Stateless_allocator use, before any work with
 *     the STL-compliant container types involved in a given SHM-stored data structure.)
 *
 * As of this writing we just provide Stateless_allocator.  `Stateful_allocator` may also be provided depending
 * on need.  It would not require the use of Arena_activator by the user; but then various difficulties inherent
 * to working with stateful allocators come into force.  (Just the fact extra bits per container instance are necessary
 * to refer to the appropriate allocator object, which knows which `Arena` to operate-upon = not super-great.)
 */
namespace ipc::shm::stl
{
 
// Types.
 
// Find doc headers near the bodies of these compound types.
 
template<typename T, typename Arena_t>
class Stateless_allocator;
 
template<typename Arena_t>
class Arena_activator;
 
// Free functions.
 
/**
 * Returns `true` for any 2 `Stateless_allocator`s managing the same Stateless_allocator::Arena.
 * This satisfies formal requirements of STL-compliant `Allocator` concept.  See cppreference.com for those formal
 * requirements.  Since it's a stateless allocator, this always returns `true`.
 *
 * @relatesalso Stateless_allocator
 *
 * @tparam Arena_t
 *         See Stateless_allocator.
 * @tparam T1
 *         See Stateless_allocator.
 * @tparam T2
 *         See Stateless_allocator.
 * @param val1
 *        An allocator.
 * @param val2
 *        An allocator.
 * @return `true`.
 */
template<typename Arena_t, typename T1, typename T2>
bool operator==(const Stateless_allocator<T1, Arena_t>& val1, const Stateless_allocator<T2, Arena_t>& val2);
 
/**
 * Returns `false` for any 2 `Stateless_allocator`s managing the same Stateless_allocator::Arena.
 * This satisfies formal requirements of STL-compliant `Allocator` concept.  See cppreference.com for those formal
 * requirements.  Since it's a stateless allocator, this always returns `false`.
 *
 * @relatesalso Stateless_allocator
 *
 * @tparam Arena_t
 *         See Stateless_allocator.
 * @tparam T1
 *         See Stateless_allocator.
 * @tparam T2
 *         See Stateless_allocator.
 * @param val1
 *        An allocator.
 * @param val2
 *        An allocator.
 * @return `false`.
 */
template<typename Arena_t, typename T1, typename T2>
bool operator!=(const Stateless_allocator<T1, Arena_t>& val1, const Stateless_allocator<T2, Arena_t>& val2);
 
} // namespace ipc::shm::stl
 
namespace boost
{
 
// Types.
 
/**
 * Specializes this boost.move trait for every ipc::shm::stl::Stateless_allocator, so as to disable the optimization
 * it controls -- in turn working around a boost.container bug in the Boost versions we support (as of this writing).
 *
 * Background: `has_trivial_destructor_after_move<X>::value == true` tells boost.container that a moved-from `X`
 * need not be destroyed.  E.g., boost.container `vector<X>::erase()` (or for `flat_map<K, X>`) then skips destroying
 * the moved-from elements.  For `X` = boost.container `basic_string`, `deque`, and `stable_vector` that trait is
 * computed as `true` if it is `true` for the `X`'s allocator type (which by default it is for any trivially
 * destructible allocator type, including ours); yet `X`'s move-assignment can leave the moved-from source owning
 * memory.  So that memory leaks.  The bug is fixed in boost.container `develop` branch but not
 * in any release through Boost-1.92 (past that version: to be seen as of this writing).  With this specialization
 * those `X` traits are `false` for `X`s using `Stateless_allocator`; so the moved-from elements are destroyed,
 * and nothing leaks.
 *
 * @note This is a legal technique; we are imposing this on `Stateless_allocator` only.  It's arguably a hack, but
 *       it is a legal hack.
 *
 * @see ticket we filed: https://github.com/boostorg/container/issues/351. It applies at least through Boost-1.92.
 *
 * The cost of this: An extra (no-op) destructor call per moved-from element *in such cases*.  It affects only
 * containers whose elements are themselves containers using Stateless_allocator; for example
 * `vector<int, Stateless_allocator<...>>` is not affected.
 *
 * @todo Once our minimum supported Boost (per our build script(s)) version includes the fix for the bug
 * worked-around by `boost::has_trivial_destructor_after_move<ipc::shm::stl::Stateless_allocator>` specialization:
 * remove that specialization.  As of Boost-1.92 the bug is there.
 *
 * @tparam T
 *         See ipc::shm::stl::Stateless_allocator.
 * @tparam Arena_t
 *         See ipc::shm::stl::Stateless_allocator.
 */
template<typename T, typename Arena_t>
struct has_trivial_destructor_after_move<::ipc::shm::stl::Stateless_allocator<T, Arena_t>>
{
  // Constants.
 
  /// Means: do not skip destroying moved-from objects whose type uses this allocator type.  See above.
  static const bool value = false;
};
 
} // namespace boost