Casper.Dik at Sun.COM wrote:
> >The only reason for supporting the numbers from Linux seems to be brandz.
>
>
> I think it's also needed to support source code.
OK, you are right
But using this argument only, we would get into pressure to implement even more
RT signals just because there
>"I. Szczesniak" 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 m
"I. Szczesniak" wrote:
> On Mon, Mar 1, 2010 at 10:15 PM, Garrett D'Amore wrote:
> > I agree with you Roger.
> >
> > You have my +1 on this case.
>
> I still disagree with the number of 32. What should developers coming
> from AIX (which has a much higher number of realtime signals) do?
I encou
"I. Szczesniak" 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
> Li
On Mon, Mar 1, 2010 at 10:15 PM, Garrett D'Amore wrote:
> I agree with you Roger.
>
> You have my +1 on this case.
I still disagree with the number of 32. What should developers coming
from AIX (which has a much higher number of realtime signals) do?
Irek
On Mon, Mar 1, 2010 at 7:32 PM, Darren J Moffat
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' argumen
On 03/ 1/10 08:56 PM, I. Szczesniak wrote:
> On Mon, Mar 1, 2010 at 10:15 PM, Garrett D'Amore wrote:
>
>> I agree with you Roger.
>>
>> You have my +1 on this case.
>>
> I still disagree with the number of 32. What should developers coming
> from AIX (which has a much higher number of re
On 03/ 1/10 08:52 PM, I. Szczesniak wrote:
> On Mon, Mar 1, 2010 at 7:32 PM, Darren J Moffat
> 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 sufficie
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
"Richard L. Hamilton" wrote:
> I'm still hoping SIGINFO will find its way back into existence. That's just
> one
> signal, hopefully there's plenty of room for it...
+1
As we still have 3 free special char entries in termios, this should not be a
problem.
J?rg
--
EMail:joerg at schily.is
I agree with you Roger.
You have my +1 on this case.
- Garrett
On 03/ 1/10 08:37 AM, Roger A. Faulkner wrote:
> Today is the timeout day for this fast-track case.
>
> So, I want to put in my final comments about the interesting,
> sometimes heated, discussion that has been going on.
>
> 1.
Today is the timeout day for this fast-track case.
So, I want to put in my final comments about the interesting,
sometimes heated, discussion that has been going on.
1. Although the idea of making {RTSIG_MAX} be a system tunable
is an intriguing possibility, it would have marginal utility.
I'm still hoping SIGINFO will find its way back into existence. That's just one
signal, hopefully there's plenty of room for it...
--
This message posted from opensolaris.org
Caution: random thoughts follow.
For situations like this where there's some question as to what can be
expanded or extended with minimal impact, why not have someone write
a DTrace script that collects info (program name, relevant system call usage)
needed to spot likely problem applications if a
> Date: Wed, 24 Feb 2010 11:27:31 -0600
> From: Nicolas Williams
> To: "Roger A. Faulkner"
> Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review]
>
> I agree with all the elided text, but would like to pick a nit.
>
> NSIG and MAXSIG
On Wed, Feb 24, 2010 at 05:11:07PM -0500, Roger A. Faulkner wrote:
> I didn't say it would not work, or that it was wrong.
> I said it would cause problems, mostly with applications
> that are not ABI conformant, by virtue of using these defines
> in array definitions:
>
> [...]
>
> Static arrays
"I. Szczesniak" wrote:
> > I find it hard to believe that more than 32 realtime signal numbers
> > is ever really needed,
>
> POSIX introduced two USR signals years ago (SIGUSR1 and SIGUSR2) and
> not one. The committee even then realised that one USR signal is not
> enough.
> In our case RT sign
"I. Szczesniak" wrote:
> > I an still not convinced that there really is a need for a huge number of RT
> > signals, it rather seems that some people wrote code without finding the
> > best
> > solution.
>
> No, it seems you didn't do any research and you did not know anything
> about realtime s
"I. Szczesniak" wrote:
> > /bin/getconf RTSIG_MAX always returns 8 on Solaris. getconf does not
> > call sysconf() for this property.
>
> As usual you don't do research before making such claims:
> /usr/bin/getconf RTSIG_MAX calls
> sysconfig(_CONFIG_RTSIG_MAX)= 8
As usual, y
On 24/02/2010 15:29, James Carlson wrote:
> I. Szczesniak wrote:
>> On Wed, Feb 24, 2010 at 8:09 AM, Roger A. Faulkner
>> wrote:
>>> and if it is then you would need a lot
>>> more than 64.
>>
>> Just speaking for our needs: 64 realtime signals are enough for our
>> needs and 32 are not.
>
> If y
On Wed, Feb 24, 2010 at 8:09 AM, Roger A. Faulkner
wrote:
> Well, I had not expected such a flurry of intense interest in this matter.
> Here's my comments on the issues/suggestions:
>
> 1. The definition of sigset_t will not be changed.
> The only issue is how much of the available signal numbe
On Wed, Feb 24, 2010 at 10:27 AM, Joerg Schilling
wrote:
> ? wrote:
>
>> Why should this be binary incompatible? The number of real time
>> signals is _dynamic_, see getconf RTSIG_MAX. The value of RTSIG_MAX is
>> defined as _tunable_ and may vary between installations of the sam
On Wed, Feb 24, 2010 at 10:37 AM, Joerg Schilling
wrote:
> ? 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:
>> Wha
On 24/02/2010 13:18, I. Szczesniak wrote:
> As usual you don't do research before making such claims:
> /usr/bin/getconf RTSIG_MAX calls
> sysconfig(_CONFIG_RTSIG_MAX)= 8
Not that I think it is in any way going to impact the outcome of the
case. However it depends exactly on
"Roger A. Faulkner" wrote:
> So what this case boils down to is, should the number of realtime
> signals be increased to 32 or to 64? (Or some other number --
> why is no one suggesting 48?)
Don't ask such a question, a similar question in the past did lead to "53" ;-)
J?rg
--
EMail:joerg
>Good.
>But the RFE I filed asked to set the number of real time signals to 64
>which does not require to change the definition of sigset_t.
Indeed; it seems that the userland sigset_t is 128 bits large (but the
kernel only uses 64)
Casper
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
? 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
> compi
I. Szczesniak wrote:
> On Wed, Feb 24, 2010 at 8:09 AM, Roger A. Faulkner
> wrote:
>> and if it is then you would need a lot
>> more than 64.
>
> Just speaking for our needs: 64 realtime signals are enough for our
> needs and 32 are not.
If you need one per thread, and you may have as many threa
? wrote:
> Why should this be binary incompatible? The number of real time
> signals is _dynamic_, see getconf RTSIG_MAX. The value of RTSIG_MAX is
> defined as _tunable_ and may vary between installations of the same
> operating system. I sounds you don't know how POSIX real tim
Well, I had not expected such a flurry of intense interest in this matter.
Here's my comments on the issues/suggestions:
1. The definition of sigset_t will not be changed.
The only issue is how much of the available signal number
space to use for realtime signal numbers.
2. S10 brand/contai
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
27;Amore"
>> Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review]
>> To: John Plocher
>> Cc: "Roger A. Faulkner" , Jordan.Vaughan at
>> Sun.COM,
> Bart.Smaalders at Sun.COM, psarc-ext at sac.sfbay.sun.com, Scott.Michael at
> Sun.COM,
The justification sounds bogus as Roland Mainz developed a patch at my
behest which sets the number of real time signals through /etc/system
between 8 and 64 in 2^m intervals, using a default of 64 with _NO_ ill
effects.
Sounds like the only reason for not setting the default to 64 is that
only 24
Why should this be binary incompatible? The number of real time
signals is _dynamic_, see getconf RTSIG_MAX. The value of RTSIG_MAX is
defined as _tunable_ and may vary between installations of the same
operating system. I sounds you don't know how POSIX real time signals
work.
FYI I filed the RFE
"I. Szczesniak" wrote:
> sigset_t is a limited resource but there are still 24 signals left
> *and* if there is ever the need to add more signals the number of
> realtime signals can be reduced again. However I strongly believe that
> there will no such demand before SunOS 6.x where sigset_t can
On Tue, Feb 23, 2010 at 11:27:53AM -0800, Garrett D'Amore wrote:
> 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.
> >
> >[...]
>
> I
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
On Mon, Feb 22, 2010 at 9:42 PM, Garrett D'Amore wrote:
> On 02/22/10 12:30 PM, Jason King wrote:
>>
>> On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore wrote:
>>
>>>
>>> On 02/22/10 12:00 PM, John Plocher wrote:
>>>
Given Roger's comment that 64 and beyone "breaks binary compatibility"
On Mon, Feb 22, 2010 at 9:42 PM, Garrett D'Amore wrote:
> On 02/22/10 12:30 PM, Jason King wrote:
>>
>> On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore wrote:
>>
>>>
>>> On 02/22/10 12:00 PM, John Plocher wrote:
>>>
Given Roger's comment that 64 and beyone "breaks binary compatibility"
On Mon, Feb 22, 2010 at 9:30 PM, Jason King wrote:
> On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore 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 *t
On Mon, Feb 22, 2010 at 8:37 PM, Garrett D'Amore wrote:
> On 02/22/10 11:28 AM, Roger A. Faulkner wrote:
>>
>> I am sponsoring this automatic case for myself.
>>
>
> +1 on the case, on the justification for not expanding to 64.
-1 for this case. I did some research on this subject and I disagree
> Date: Mon, 22 Feb 2010 13:42:39 -0800
> From: "Garrett D'Amore"
> Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review]
> To: "I. Szczesniak"
> Cc: Jason King , Krister.Johansen at sun.com,
Scott.Michael at sun.com, "Ro
> Date: Mon, 22 Feb 2010 12:11:56 -0800
> From: "Garrett D'Amore"
> Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review]
> To: John Plocher
> Cc: "Roger A. Faulkner" , Jordan.Vaughan at
> Sun.COM,
Bart.Smaalders
On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore 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 O
I am sponsoring this automatic case for myself.
The number of realtime signals supported by Solaris is quite small (8).
This is the minimum number required for Posix branding.
However, other systems provide many more.
Linux supports 32-64 realtime signals depending on the architecture,
BSD does 3
On Mon, Feb 22, 2010 at 10:17:34PM +0100, I. Szczesniak wrote:
> On Mon, Feb 22, 2010 at 8:37 PM, Garrett D'Amore wrote:
> > On 02/22/10 11:28 AM, Roger A. Faulkner wrote:
> >>
> >> I am sponsoring this automatic case for myself.
> >>
> >
> > +1 on the case, on the justification for not expanding
Irek,
You seem to believe that there is a compelling need for > 32 real time
signals. Can you provide some justification for this? Are there any
specific examples you can cite that will not function well with only 32
such signals?
As far as your idea of reducing signals in the future -- I'm
On 02/22/10 12:30 PM, Jason King wrote:
> On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore 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 *th
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 poin
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 d
On 02/22/10 11:28 AM, Roger A. Faulkner wrote:
> I am sponsoring this automatic case for myself.
>
+1 on the case, on the justification for not expanding to 64.
IMO, this pushes the boundary of what's permissible in a self-review,
but I see no reason to promote it to a full fast track at thi
52 matches
Mail list logo
