Merge pull request #102 from Flow-IPC/polish

Style refactor (small): Encouraging static_assert(false) over #error. Encouraging if constexpr over SFINAE. / Comment and/or doc changes.
Flow-IPC · Mar 30, 2024 · c0727e7 · c0727e7
2 parents 687feda + 50b7b31
commit c0727e7
Show file tree

Hide file tree

Showing 9 changed files with 9 additions and 9 deletions.
diff --git a/flow b/flow
diff --git a/ipc_core b/ipc_core
diff --git a/ipc_session b/ipc_session
diff --git a/ipc_shm b/ipc_shm
diff --git a/ipc_shm_arena_lend b/ipc_shm_arena_lend
diff --git a/ipc_transport_structured b/ipc_transport_structured
diff --git a/src/doc/manual/a-about.dox.txt b/src/doc/manual/a-about.dox.txt
@@ -112,7 +112,7 @@ We feel this is a comprehensive work, but there is always more to achieve.  Beyo
   - **Networked IPC**: At the moment all IPC supported by Flow-IPC is between processes within a given machine (node).  A session can only be established that way for now.  Extending this to establish IPC sessions via network would be easy.  Unix-domain-socket-based low-level transports would easily be extended to work via TCP sockets (at least).  This is a very natural next step for Flow-IPC development: a low-hanging fruit.
   - **Networked "shared memory" (RDMA)**: While the preceding bullet point would have clear utility, naturally the zero-copy aspect of the existing Flow-IPC cannot directly translate across a networked session: It is internally achieved using SHM, but there is no shared memory between two separate machines.  There *is*, however, [Remote Direct Memory Access (RDMA)](https://en.wikipedia.org/wiki/Remote_direct_memory_access): direct memory access from the memory of one computer into that of another without involving either one's OS.  While assuredly non-trivial, leveraging RDMA in Flow-IPC might allow for a major improvement over the feature in the preceding bullet point, analogously to how SHM-based zero-copy hugely improves upon basic IPC.
   - **Beyond C++**: This is a C++ project at this time, but languages including Rust and Go have gained well-deserved popularity as well.  In a similar way that (for example) Cap'n Proto's original core is in C++, but there are implementations for other languages, it would make sense for the same to happen for Flow-IPC.  There are no technical stumbling blocks for this; it is only a question of time and effort.
-  - **More architectures**: As of this writing, Flow-IPC targets Linux + x86-64.  MacOS/Darwin/FreeBSD support is attainable with a few weeks of work, we estimate.  (Could tackle Windows as well.)  Supporting other hardware architectures, such as ARM64, is also doable and valuable.  We'd like to do these things: by far most of the code is platform-independent, the exceptions being certain internal low-level details typically involving shared memory and pointer tagging in the SHM-jemalloc sub-component.
+  - **More architectures**: As of this writing, Flow-IPC targets Linux + x86-64.  macOS/Darwin/similar support is attainable with a few weeks of work, we estimate.  (Could tackle Windows as well.)  Supporting other hardware architectures, such as ARM64, is also doable and valuable.  We'd like to do these things: by far most of the code is platform-independent, the exceptions being certain internal low-level details typically involving shared memory and pointer tagging in the SHM-jemalloc sub-component.
 
 We welcome feedback, ideas, and (of course) pull requests of all kinds!
 

diff --git a/src/doc/manual/c-setup.dox.txt b/src/doc/manual/c-setup.dox.txt
@@ -30,7 +30,7 @@ OS and build environment
 ------------------------
 @note In the short term (as of October 2023) this may become an open-source library with potentially wide distribution.  Some of the below items may change in that case; for example it may become a header-only library or have that mode, and it may support additional OS rather than Linux.  We would also include specific information on building it from source as befits a wide-release project.  Until then we leave out specific instructions on building the library itself as outside the scope of the present document; while listing the environmental requirements/recommendations as follows.  It is vaguely informational; until this is a wide-release library we stay away from rigorous build instructions here.  Even once it becomes a wide-release product, possibly such instructions shall live outside this manual.  Looking outside the src/ directory you'll certainly find the relevant build scripts which cover all that.
 
-This is a Linux library (actually set of libraries, but in this Manual we treat Flow-IPC as a monolithic whole for simplicity).  As of this writing it is to be built in 64-bit mode (x86-64 a/k/a AMD64).  (Most code by far is not OS/architecture-specific, but at least certain aspects of the optionally-used SHM-jemalloc component are.)  It is intended for use *at least* in a deployed server setting.  As of this writing it relies on some Linux-specific techniques such as /proc/...pid.../ and /dev/shm/ semantics.  In the future it is quite realistic it would be extended to other OS and architectures -- possibly even Windows, but definitely MacOS/Darwin and FreeBSD and orthogonally perhaps ARM64 and so on.
+This is a Linux library (actually set of libraries, but in this Manual we treat Flow-IPC as a monolithic whole for simplicity).  As of this writing it is to be built in 64-bit mode (x86-64 a/k/a AMD64).  (Most code by far is not OS/architecture-specific, but at least certain aspects of the optionally-used SHM-jemalloc component are.)  It is intended for use *at least* in a deployed server setting.  As of this writing it relies on some Linux-specific techniques such as /proc/...pid.../ and /dev/shm/ semantics.  In the future it is quite realistic it would be extended to other OS and architectures -- possibly even Windows, but definitely macOS/Darwin/similar and orthogonally perhaps ARM64 and so on.
 
 It is a linked library (libraries) that must be built in **C++17** compiler mode, as must any of its `#include`rs (translation units).  It has been specifically tested (as of this writing) on a range of gcc and clang compilers/linkers.  We omit details in this text, since this is likely to evolve over time.  Generally such topics are well covered outside of src/ directories; start with the top-level `README.md` for an overview; it will point you to CMake scripts and so on -- if there is interest.
 

diff --git a/test/suite/transport_test/ex_guy.hpp b/test/suite/transport_test/ex_guy.hpp
@@ -225,7 +225,7 @@ bool Ex_guy::run(bool srv_else_cli, Task&& body)
 
     FLOW_LOG_INFO("Determining our location to ensure it matches [" << exp_bin_path << "].");
 #ifndef FLOW_OS_LINUX
-#  error "We expect Linux in this test/demo program."
+    static_assert(false, "We expect Linux in this test/demo program.");
 #endif
     const auto bin_path = fs::read_symlink("/proc/self/exe"); // Can throw.
     if (bin_path != exp_bin_path)