Re: [interprocess] Mutex and condition at process termination

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2020-05-19 10:32:25

Niall Douglas wrote:
> The latest revision of the "modern signals" paper can be found at
> https://wg21.link/P2069.

Thanks Niall, that's interesting.

I note that your signal_guard takes a callable.  That's not easy
to combine with a scoped lock_guard, i.e. if I want to make
something that's exactly like std::lock_guard but also blocks
SIGINT.  Is there any way around that?

To block SIGINT for the short time that a lock is held, I was
imagining calls to pthread_sigmask() when locking and unlocking -
but I guess this is an actual system call, so it could take
much longer than the mutex lock and unlock, which are just
atomics typically.  If I understand correctly, your proposal
avoids this by installing a signal handler once at startup, and
then just changing some state at the start and end of the guard.
So if I want only to block a signal rather than ignoring or
handling it, with your proposal I would need to track pending
signals and raise them at the end of the guard.  Is that right?

I'm unclear what happens in a multi-threaded program; if one
thread is in a critical section with SIGINT blocked, can the
signal be delivered to a different thread and cause the whole
process to be terminated, defeating the purpose of blocking it?
Does your proposal change this behaviour, compared to
pthread_sigmask() ?

Regards, Phil.