Some questions about Linux signals
-
Is (
SIGRTMIN + 1
) safe for interprocess communication? Will it change in different processes? -
Is there any difference in using
sigqueue(2)
orkill(2)
for sending standard signals and signals in real time?
If I usesigqueue(2)
to send a seriesSIGUSR1
(standard signals) and process them slowly, are there multiple instances in the queueSIGUSR1
?
How about usingkill(2)
to sendSIGRTMIN
(real-time signals)? Will they be queued up?
sigqueue () can be used to send only realtime signals and kill () can be used to send only standard signals. I have not tried to send the wrong signal using the API. But I would expect it to fail with some relevant error. Linux does not queue standard signals. Real-time signals are queued. The maximum number of real-time signals that can be queued is defined as RLIMIT_SIGPENDING
You can use any real-time signal as long as the receiver has a handler set up to send a specific sender.
EDIT
I was wrong earlier in my answer. It looks like kill () can send signals in real time. But from the comment in __send_signal () it looks like using kill to send signals in real time may not have the desired effect in some cases, that is: signals may not be queued.
/*
* Real-time signals must be queued if sent by sigqueue, or
* some other real-time mechanism. It is implementation
* defined whether kill() does so. We attempt to do so, on
* the principle of least surprise, but since kill is not
* allowed to fail with EAGAIN when low on memory we just
* make sure at least one signal gets delivered and don't
* pass on the info struct.
*/
This post is old news, but it ranks high on Google and is unfortunately misleading, so here are some clarifications:
- You can send any signal using any of these functions.
- sigqueue allows more "context" to be passed (eg info, @see siginfo et. al] as opposed to kill / raise
- According to real-time signals - it doesn't matter if they are sent or queued - they will behave the same [for example, in queue cf. grouped as signals without RT]