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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk