Replace signals!
Replace signals!
Posted Jan 10, 2022 9:57 UTC (Mon) by roc (subscriber, #30627)In reply to: Replace signals! by NYKevin
Parent article: VSTATUS, with or without SIGINFO
I think my preferred behavior for signalfd would be that the signal is available through the fd if and only if it is blocked in the process that is the source of the signalfd, i.e. if the signal is unblocked (by the user or in the synchronous case) then signalfd doesn't get it.
> Anyway, the purpose of signalfd is not to share signals with other processes
Maybe that's not the original purpose, but the whole point of orthogonal API design and "everything is a file" is that you can compose features to address new use cases not anticipated by the designers of the individual APIs.
In rr and Pernosco we have a couple of instances of a non-uncommon case: the user runs a process A that in some cases forwards its work to another process B in an unrelated part of the process tree. We want signals like SIGINT, SIGTERM etc sent to A to be handled in B. signalfd looks like it should work for this, but it doesn't, because it has this very strange behavior that what you read from the file descriptor depends on which process is reading from it. Instead we pretend it's the 1980s and install signal handlers that write data to a pipe.
Posted Jan 10, 2022 19:40 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
I see. That makes a great deal of sense to me, but I would still be concerned about all of the following:
* What data structure holds the list of pending signals for a given process or thread? How thread-safe is this structure?
> I think my preferred behavior for signalfd would be that the signal is available through the fd if and only if it is blocked in the process that is the source of the signalfd, i.e. if the signal is unblocked (by the user or in the synchronous case) then signalfd doesn't get it.
* Does this cause thread-safety issues with pselect, which has to atomically (modify the signal mask) and (wait for FD events)? What if you use pselect to unmask a signal which is associated with a signalfd that you are pselecting against? I should expect that to Just Work (i.e. it always executes the signal handler and never returns a ready-to-read event for the signalfd), regardless of when the signal arrives. Is the current implementation prepared to do that?
Posted Jan 10, 2022 20:29 UTC (Mon)
by roc (subscriber, #30627)
[Link] (1 responses)
> What if you use pselect to unmask a signal which is associated with a signalfd that you are pselecting against?
The signal will be delivered normally and not be received by the signalfd. That seems to be the only reasonable behavior.
Posted Jan 10, 2022 20:32 UTC (Mon)
by roc (subscriber, #30627)
[Link]
Replace signals!
* Is it possible to atomically dequeue a signal from the list, without taking a mutex?
* If the above is not currently possible, what would be the performance overhead of modifying the data structure so that it is amenable to atomic operations?
* What does the existing "inject a signal handler" code path look like? Can the dequeue be cleanly separated from the injection, or are they tightly coupled? Presumably, you have to preempt the thread before the dequeue (to prevent the thread from exiting or blocking the signal before you can inject the handler), so I imagine there must be some amount of coupling there...
Replace signals!
Replace signals!