Boost logo

Boost :

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at