nullplan wrote:
on thread exit, if an unblocked signal is pending for the process and all other threads are sleeping, wake up another thread.
Seems like an approach worth considering. There might be challenges around determining if all threads are sleeping, since there's no straightforward way to do that atomically. But perhaps all that matters is determining if there is at least one thread that is awake and not blocking the signal. I'll think through it a bit.
By the way, it occurred to me that there are also situations involving threads updating their signal masks that can lead to unnecessary delays in delivering process signals. For example, imagine the same scenario I described in my previous post, but instead of exiting, the one thread that is awake updates its mask to block the signal before it gets a chance to deliver it. Now we have a situation where there is a live thread blocking the signal, and other sleeping threads that are not blocking the signal. Once again, the signal will not get delivered for an indeterminate period even though there are threads that could deliver it. I suppose one can take a similar approach to what you suggested for thread exit and check when updating a signal mask whether any pending process signals will be blocked, and if so, whether another thread might need to be woken up. Starts to feel a bit messy though, and there might still be remaining edge cases.
Quote:
By the way, thank you for the idea, I hadn't thought of that problem yet.
You are welcome. And thank you for suggesting a potential solution.