On 02/23/10 10:10 AM, ????? ???????????? wrote:
> It is not possible to implement a compile time flag which defines the
> number of real time signals. RTSIG_MAX is a global property of the
> operating system.
>
> Just think this proposal through:
> What if kill -RTMIN+62 82939 is send to a process which is not
> compiled with this flag? Should it ignore the signal, call abort() or
> panic the system?
> What if a script uses /bin/getconf RTSIG_MAX to determinate the number
> of real time signals - getconf being compiled with your proposed flag
> - and the shell is not compiled with your proposed compile time flag
> and supports 8 signals only?
>
I agree that this doesn't sound like a good option. I was conjecturing.
I intend to ask Roger for clarification as to why we can't make this
tunable. It seems like an /etc/system tunable defaulting to 32 but
allowing it to grow to up to 64 *might* work -- it might even be the
case that we can default to 64. What I don't know is what other plans
there might be for the remaining signals.
We do add new signal uses from time to time -- albeit not very often.
Growing the list may have good benefits for realtime apps, but may have
negative impact on our ability to evolve other parts of the system.
- Garrett
> Olga
>
> On Mon, Feb 22, 2010 at 9:42 PM, Garrett D'Amore<gdamore at sun.com> wrote:
>
>> On 02/22/10 12:30 PM, Jason King wrote:
>>
>>> On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore<gdamore at sun.com>
>>> wrote:
>>>
>>>
>>>> On 02/22/10 12:00 PM, John Plocher wrote:
>>>>
>>>>
>>>>> Given Roger's comment that 64 and beyone "breaks binary compatibility"
>>>>> and should only be done on a major release boundry, isn't *this* the
>>>>> exact right time to do so? The Solaris10 to OpenSolaris Enterprise
>>>>> change IMO *is* such a major release point. There won't be such an
>>>>> opportunity again for decades...
>>>>>
>>>>>
>>>>>
>>>> OpenSolaris still retains most of the binary compatibility with Solaris
>>>> Nevada. Unless there is a really compelling reason, I'd be loathe to
>>>> support any change which breaks existing S10 binaries.
>>>>
>>>> The ARCs are still (I believe) operating on the assumption that Solaris
>>>> Next
>>>> and/or OpenSolaris represent a "pseudo major" release boundary. This
>>>> means
>>>> that we can allow some interface breakage where it makes sense, but we
>>>> are
>>>> still expected to try to ensure that most normal applications that work
>>>> on
>>>> Solaris 10 and earlier will continue to function on the next release.
>>>>
>>>> We actually have more flexibility, IMO, in administrative interfaces such
>>>> as
>>>> dladm, packaging, etc.
>>>>
>>>>
>>> Isn't this what S10 containers are for? Could this be done in a way
>>> that S10 containers still run things correctly, while 'new' stuff gets
>>> the advantage of having the upper limit? As John said, the
>>> opportunity probably won't arise to revisit this again for a very
>>> long time, and as a customer who was burned for a very long time by
>>> the 256 fd limit for stdio (until a rather clever workaround was
>>> created), I'd be loathe to revisit similar limitations if it appears
>>> we are starting to approach them.
>>>
>>>
>> You should not have to use a Container to run *any* S10 application, which
>> is what such a change would effectively cause. It would create huge
>> heartache and pain for everyone involved, and create a *serious* impediment
>> for moving customers to using OpenSolaris.
>>
>> If there was a really compelling argument, I can see investigating a way for
>> applications to be built with a special flag that enables this (not even
>> sure if that is possible) ala the 64-bit file offset flags, but I haven't
>> heard any compelling evidence that more than 32 such signals is actually
>> necessary for any real world applications.
>>
>> - Garrett
>>
>>
>> _______________________________________________
>> opensolaris-arc mailing list
>> opensolaris-arc at opensolaris.org
>>
>>
>
>
>
