To make it clear - there is no magic tunable to change the number
of RT signals. It requires changing source (catching every place the
current data structures used are too small) and rebuilding.
Jim
----
James Litchfield wrote:
ольга крыжановская wrote:
On 3/22/09, Joerg Schilling <[email protected]> wrote:
????? ???????????? <[email protected]> wrote:
> Can I increase the number of POSIX realtime signals? I have a
> commercial application running on Linux 386 which refuses to run
in a
> brandz zone because brandz only supports 8 realtime signals
instead of
> the 32 required by LSB and supported by Linux 386.
If the program _needs_ more than 8 RT signals, it is not POSIX
compliant.
All that POSIX says is that if you claim conformance to the realtime
signals extension, you must support "realtime" signal behavior for
signals numbered between between SIGRTMIN and SIGRTMAX (values
of which are implementation dependent) and that the delta between
SIGRTMIN and SIGRTMAX must be at least 8. Having 17 or 32 signals
offering realtime behavior is quite acceptable and would not break
compliance
if the implementation claimed compliance.
I don't think the LSB claims they are POSIX conformant. They offer the
API
which is perfectly permissible. POSIX says nothing about
interoperaibility
between differing numbers of realtime signals or even what "realtime"
means.
The only real requirements are about the information offered when signals
are delivered and that with multiple signals pending in the range
SIGRTMIN to
SIGRTMAX, they must be delivered in order from lowest to highest.
An interesting question is whether the app does the "right" thing and
asks
what SIGRTMIN and SIGRTMAX are and adjusts accordingly or whether those
values are wired into the app via a #define or equivalent. If they're
wired in,
changing the number of realtime signals may not buy you anything.
SIGRTMIN is 41 on OpenSolaris and SIGRTMAX is 48. I don't know
what the equivalent Linux values are.
The change is likely not as simple as increasing _SIGRTMAX in
the relevant include file and rebuilding. The proc structure, for
example,
in Solaris seems to use a 64 bit mask to track signals.
Jörg, I am talking about the POSIX signal API, not POSIX standards
conformance. Fact is that Linux supports 32 realtime signals and
brandz causes application failures because it only does 8.
_______________________________________________
brandz-discuss mailing list
[email protected]
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code