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.