On 18/05/2020 14:38, Bjorn Reese via Boost wrote:
On 2020-05-17 21:40, Niall Douglas via Boost wrote:
The proposal to mark standard library functions as async signal safe, or alternatively as non-allocating, does not sound feasible given the committees reluctance to mark standard library functions as noexcept (Lakos rule.)
FYI I believe the Lakos rule is going away soon in any case, as we shall be gaining better ways of solving the problem it solved, and still marking functions obviously noexcept as noexcept. Re: async signal safe, I believe EWG-I guidance was that marking all standard library functions is infeasible, but that marking "core" standard library functions is desirable, for some definition of "core". In theory, one could then deduce async signal safety of some arbitrary use of the standard library, or to be more specific, the compiler could deduce it for you. In practice, I think people will subset the C++ they use within signal guarded sections. The requirement that no non-trivial destructors could ever be called is fairly limiting in any case, it precludes the portable use of much of the standard library. Coming back to shared memory mutexes etc, me personally if I want a mutex that is shared across processes and is resilient to sudden process death, I just lock a shared file in /tmp using flock(). This is completely portable: LLFIO, thanks to recent WG21 feedback, now implements SharedMutex Concept matching file_handle. Rather usefully, the content of the same shared file can also be the shared memory between the processes. One thus has exactly what the OP is looking for. Niall