Boost logo

Boost :

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-05-19 12:55:56


On 18/05/2020 14:38, Bjorn Reese via Boost wrote:
> On 2020-05-17 21:40, Niall Douglas via Boost wrote:
>
>> https://wg21.link/P2069.
>
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk