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: >> >> 2. The number of realtime signals (32 or 64) has been vigorous debated. >> >> I argued that sigqueue() could be used for sending signals with >> its additional 'union sigval' argument providing for many more >> discriminating values than just the number of realtime signal numbers. >> >> In support of this position, I found this statement in the latest >> Posix standard (IEEE Std 1003.1(tm)-2008): >> >> Rationale for System Interfaces >> >> B.2.4.2 Realtime Signal Generation and Delivery >> >> An application-defined value passed to the signal handler is used >> to differentiate between different "events" instead of requiring >> that the application use different signal numbers for several >> reasons: >> >> - Realtime applications potentially handle a very large number of >> different events. Requiring that implementations support a >> correspondingly large number of distinct signal numbers will >> adversely impact the performance of signal delivery because the >> signal masks to be manipulated on entry and exit to the handlers >> will become large. >> >> - Event notifications are prioritized by signal number (the >> rationale >> for this is explained in the following paragraphs) and the use of >> different signal numbers to differentiate between the different >> event notifications overloads the signal number more than has >> already been done. It also requires that the application developer >> make arbitrary assignments of priority to events that are >> logically >> of equal priority. >> >> I stand firm on my proposal to make the number be 32. > > 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. Irek
