[systemd-bugs] [Bug 84931] hppa can't handle SIGRTMIN+29

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84931

Mike Gilbert <floppym at gentoo.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |REOPENED

--- Comment #2 from Mike Gilbert <floppym at gentoo.org> ---
(In reply to Lennart Poettering from comment #1)
> Hmm, did I get this right? SIGRTMAX-SIGRTMIN is different for Linux on hppa
> than for Linux on all other archs?

Yes.

> What's the last SIGRTMIN+n that works on hppa? Or in other words, what is
> SIGRTMAX-SIGRTMIN? If you let me know we'll just skip all signal assignments
> beyond this value on #ifdef __hppa__

>From the Gentoo bug that Pacho linked, it seems that SIGRTMIN is 39 on hppa. I
assume SIGRTMAX is still 64, so that would make the difference 25.

> Note that the signals we expose are kinda API, hence we cannot dynamically
> assign them. Hence checking things against SIGRTMAX and shifting things
> around is really not a good idea. And normally this wouldn't be a problem as
> on Linux/glibc the number of rt sigs should be stable and fixed. Apparently
> though with the exception of Linux/hppa...

You are probably familiar, but signal(7) says:

"... 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."

Ideally, systemd would just use a smaller range of signals, without gaps.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20141024/78eafaa5/attachment.html>