On Wed, Feb 24, 2010 at 02:09:21AM -0500, Roger A. Faulkner wrote: > 4. The system tunable idea (set via /etc/system and nothing else) > is something that had not occurred to me. It would be possible. > > I think it would cause more problems than it would be worth, though. > For one, it would require these defined values to become variables: > NSIG > MAXSIG > and, regrettably, there are lots of applications out there that > use these numbers in array specifications.
I agree with all the elided text, but would like to pick a nit. NSIG and MAXSIG are compile-time constants, yet we propose increasing the number of signals. Clearly the fact that NSIG and MAXSIG are constants does not prevent the system from gaining more signals. And presumably programs that wish to use many real-time signals will be using sysconfig(_CONFIG_RTSIG_MAX) (and/or _CONFIG_SIGRT_MIN and _CONFIG_SIGRT_MAX) instead of NSIG/MAXSIG. Therefore it seems perfectly reasonable to have NSIG/MAXSIG become variables without having to recompile all programs that use them. And it seems perfectly reasonable to have the number of RT signals be variable even though NSIG/MAXSIG are constants. > Second, I believe it would be a violation of the principle of > least astonishment for an application that uses realtime signals > to behave differently on different Solaris systems, all running > exactly the same operating system, with only a one line difference > in their respective /etc/system files. I'm not entirely sure, but it seems to me that if the standard provides for a sysconfig for discovering the RT signal range, then surely it allows for the number of RT signals to be variable from boot to boot. If so then the principle of least surprise does not apply as you suggest. Nico --
