On 03/ 1/10 08:52 PM, I. Szczesniak wrote:
> On Mon, Mar 1, 2010 at 7:32 PM, Darren J Moffat<Darren.Moffat at sun.com>
> wrote:
>
>> On 01/03/2010 16:37, Roger A. Faulkner wrote:
>>
>>>
>> With the information in "IEEE Std 1003.1(tm)-2008" I think the proposal is
>> sound to use 32. It provides sufficient "Linux compatibility" and is inline
>> with standards recommendations.
>>
> Where is the ARC case which requires that Solaris defaults must match
> Linux defaults and not those from BSD or AIX? Without such a case this
> argument is invalid.
>
There is no such case. Indeed, there is no case requiring us to match
even Linux. Its a matter of judgment on the part of the case submitter
and on the reviewers. (We *do* have to at least try to conform to
POSIX, but that's a different matter, since we're conformant in this
regard even with just 8 real-time signals.)
We are trying to be compatible with Linux because it helps with the bulk
of folks who come from foreign environments, and it helps with our Linux
emulation support (Brand LX).
Roger's investigation shows that architecturally, there is no compelling
need for more than 32 such real time signals -- even if you want to use
them in your software, you're probably better off using sigqueue() to
separate out the different events.
Ultimately, you probably aren't going to be happy with our decision here
to only support 32 signals (still better than just 8 though!), but I
think we can be satisfied that we have at least heard and thoughtfully
considered your arguments in favor of expanding this 64.
(Even individual members often are unhappy with the results of ARC
cases... too often we wind up making compromises we don't like. But no
one member has the power to cause a case to be approved or denied. The
only difference between members and non-members in this regard is a)
members can force a vote (which I've already done for this case), and b)
members get to vote, but they only get one vote each where a simple
majority is sufficient to pass a case.)
- Garrett
