Add SIGRTMIN..SIGRTMAX signals.#1705
Add SIGRTMIN..SIGRTMAX signals.#1705unshare wants to merge 1 commit intoopencontainers:masterfrom unshare:pr-1
Conversation
Actually, it's ported Moby's signal map. If not added this way, `parseSignal` returns "unknown signal %q". Signed-off-by: Valentin Kulesh <valentin.kulesh@virtuozzo.com>
|
502 (bad gateway) from go.googlesource.com is definitely unrelated CI failure |
|
@unshare restarted the CI for ya |
|
|
||
| const ( | ||
| sigrtmin = 34 | ||
| sigrtmax = 64 |
There was a problem hiding this comment.
It's not a good idea to hardcode these, for two reasons:
-
glibcuses the top two (or three in some cases)SIGRTsignals forNPTL(7), which could cause confusion for users (especially since this means thatSIGRTMAXwould be different forruncthan it is forkillor regular processes). -
It's possible that in the future the kernel will support more realtime signals. While this is unlikely, hardcoding this is less optimal than using the
SIGRTMINandSIGRTMAXmacros IMO.
There was a problem hiding this comment.
Go SDK doesn't provide SIGRTMIN and SIGRTMAX. It could be a good idea to go there first and return here afterwards, but I don't think I have great chances. Docker/Moby didn't do it.
There was a problem hiding this comment.
You could access them through CGo (though it would be a bit ugly).
There was a problem hiding this comment.
Yeah, I know. It's how it's done in Go SDK for some OSes (but not for Linux -- for Linux it's hard-coded). It's hard-coded in Python, too. And in Moby/Docker. Different people have different opinions.
But signal map completeness is not the issue. See #1706
| "RTMAX-3": sigrtmax - 3, | ||
| "RTMAX-2": sigrtmax - 2, | ||
| "RTMAX-1": sigrtmax - 1, | ||
| "RTMAX": sigrtmax, |
There was a problem hiding this comment.
I'm not sure I understand the justification of having SIGRTMAX-n signal "names". Almost all usages I've seen of SIGRT have always been either SIGRTMIN+n or SIGRTnn. This matches the man page's recommentation:
programs should never refer to real-time signals using hard-coded numbers, but instead should always refer to real-time signals using the notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does not exceed SIGRTMAX.
There was a problem hiding this comment.
|
Closing in favor of #1706 |
3 participants
Actually, it's ported Moby's signal map. If not added this way,
parseSignalreturns "unknown signal %q".