From sacadmin Mon Feb 22 11:18:20 2010 Received: from rafblade (punchin-raf.SFBay.Sun.COM [10.7.251.247]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MJIKQ9003650 for ; Mon, 22 Feb 2010 11:18:20 -0800 (PST) Received: from rafblade (localhost [127.0.0.1]) by rafblade (8.14.4+Sun/8.14.4) with ESMTP id o1MJIHrM147085; Mon, 22 Feb 2010 14:18:18 -0500 (EST) Received: (from raf@localhost) by rafblade (8.14.4+Sun/8.14.4/Submit) id o1MJIHe2147081; Mon, 22 Feb 2010 14:18:17 -0500 (EST) Date: Mon, 22 Feb 2010 14:18:17 -0500 (EST) From: "Roger A. Faulkner" Message-Id: <201002221918.o1MJIHe2147081@rafblade> To: PSARC-record@sac.sfbay.sun.com Subject: increase number of realtime signals [PSARC/2010/062 Self Review] Status: RO Content-Length: 574 Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: increase number of realtime signals 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 22 February, 2010 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From raf@jurassic.sfbay.sun.com Mon Feb 22 11:28:20 2010 Received: from jurassic.Eng.Sun.COM (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MJSKdh003780 for ; Mon, 22 Feb 2010 11:28:20 -0800 (PST) Received: from rafblade (punchin-raf.SFBay.Sun.COM [10.7.251.247]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with SMTP id o1MJSI0M733311; Mon, 22 Feb 2010 11:28:19 -0800 (PST) Message-Id: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> Date: Mon, 22 Feb 2010 14:28:18 -0500 (EST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: increase number of realtime signals [PSARC/2010/062 Self Review] To: psarc-ext@sac.sfbay.sun.com Cc: Scott.Michael@sun.com, krister.johansen@sun.com, bart.smaalders@sun.com, jordan.vaughan@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LbdvH8kfyox8P5GoW3rmXQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1814 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 32 or 64 depending on architecture, AIX supports 111. This affects Solaris directly in that the Linux zone provided by Solaris cannot support Linux applications that use more than 8 realtime signals. See the bug report: 6820733 lack of realtime signals causes Linux application in BrandZ to fail which is a duplicate of the more general bug report: 6820737 Solaris needs to increase the number of realtime signals for platform parity This case proposes to increase the number of realtime signals supported by Solaris from 8 to 32. Why not just go to 64, one might ask? The reason is contained in the 6820737 bug report's Evaluation: Now, as to the request to increase the number of real-time signals to 64, this would more than double the currently supported number of signals. The sigset_t structure, in its present definition, can only support a maximum of 128 signals. It's a limited resource. Increasing the number of real-time signals to 64 would leave only 24 bits remaining in the sigset_t definition for future expansion. We need more wiggle-room than that for future expansion. So, when the number of real-time signals is increased, it will only be increased to 32, not 64. We can increase to 64 only by changing the definition of sigset_t and this breaks binary compatibility, so this can be done only when we move from Solaris 2.x to Solaris 3.x (or whatever the next naming scheme will be called). Roger Faulkner From gdamore@sun.com Mon Feb 22 11:37:17 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MJbHEJ004025 for ; Mon, 22 Feb 2010 11:37:17 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MJbHnx003839 for ; Mon, 22 Feb 2010 11:37:17 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1MJbCmI023129 for ; Mon, 22 Feb 2010 11:37:12 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY900400CXZ0100@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 11:37:12 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY900KHUD5YUD30@fe-sfbay-09.sun.com>; Mon, 22 Feb 2010 11:37:11 -0800 (PST) Date: Mon, 22 Feb 2010 11:37:10 -0800 From: "Garrett D'Amore" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com Message-id: <4B82DCE6.4050201@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 2182 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 this point. -- Garrett > 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 32 or 64 depending on architecture, AIX supports 111. > > This affects Solaris directly in that the Linux zone > provided by Solaris cannot support Linux applications > that use more than 8 realtime signals. See the bug report: > 6820733 lack of realtime signals causes Linux application > in BrandZ to fail > which is a duplicate of the more general bug report: > 6820737 Solaris needs to increase the number of realtime signals > for platform parity > > This case proposes to increase the number of realtime signals > supported by Solaris from 8 to 32. > > Why not just go to 64, one might ask? > The reason is contained in the 6820737 bug report's Evaluation: > > Now, as to the request to increase the number of real-time signals > to 64, this would more than double the currently supported number > of signals. The sigset_t structure, in its present definition, > can only support a maximum of 128 signals. It's a limited resource. > Increasing the number of real-time signals to 64 would leave only > 24 bits remaining in the sigset_t definition for future expansion. > We need more wiggle-room than that for future expansion. > > So, when the number of real-time signals is increased, it will only > be increased to 32, not 64. We can increase to 64 only by changing > the definition of sigset_t and this breaks binary compatibility, > so this can be done only when we move from Solaris 2.x to Solaris 3.x > (or whatever the next naming scheme will be called). > > Roger Faulkner > > From john.plocher@gmail.com Mon Feb 22 12:00:02 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MK01Nk004822 for ; Mon, 22 Feb 2010 12:00:02 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MK01pr017312 for ; Mon, 22 Feb 2010 12:00:01 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1MJsRZx024131 for ; Mon, 22 Feb 2010 20:00:01 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-907147 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 20:00:01 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-14696643 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 20:00:00 Z Received: from qw-out-2122.google.com ([74.125.92.27] [74.125.92.27]) by relay1i.sun.com with ESMTP id BT-MMP-33154994 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 20:00:00 Z Received: by qw-out-2122.google.com with SMTP id 9so408312qwb.63 for ; Mon, 22 Feb 2010 12:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d0BRcWOnx6+7LAMT2Bv3r8CnIW8F+EspQdcYC6Uvldg=; b=nwcP7erNwPrWACH2gv4z3HXkWdYDuCiFOdqiCHmtOySRHpsnzeOBwiB1BFecgzuvm8 6O0ChQN6VZ7ZGUaRP48LnOFEt3Umvfk48oP5Pe5wv387GBh+C3rB7HNhZ+386KhNtAiH 8BIlAxdkl2bbeD+OUV4+h42/s/KDgRYcuCnWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pGcchthmdf2GtCGuRKqXXmrJOrWo8zfldMB5DYJz5oWt2CxnRIXhV/CmctuRNT9rLe ZcfBhjx8WSaVlVNvC/fo8P1NpCIpMYah8sW714pFBIIu2u47VpjuFFgjyV7pHsfHzNVb Fj1f7nGKXCWS4dL4blSUt63SXlPF/xG0b+h6A= Received: by 10.229.129.29 with SMTP id m29mr595427qcs.33.1266868800457; Mon, 22 Feb 2010 12:00:00 -0800 (PST) In-Reply-To: <4B82DCE6.4050201@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> Date: Mon, 22 Feb 2010 12:00:00 -0800 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: John Plocher To: "Garrett D'Amore" Cc: "Roger A. Faulkner" , Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com, psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.077sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o1MK01Nk004822 Status: RO Content-Length: 2728 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... -John On Mon, Feb 22, 2010 at 11:37 AM, 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. > > 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 this point. > >    -- Garrett > >> 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 32 or 64 depending on architecture, AIX supports 111. >> >> This affects Solaris directly in that the Linux zone >> provided by Solaris cannot support Linux applications >> that use more than 8 realtime signals.  See the bug report: >>     6820733 lack of realtime signals causes Linux application >>             in BrandZ to fail >> which is a duplicate of the more general bug report: >>     6820737 Solaris needs to increase the number of realtime signals >>             for platform parity >> >> This case proposes to increase the number of realtime signals >> supported by Solaris from 8 to 32. >> >> Why not just go to 64, one might ask? >> The reason is contained in the 6820737 bug report's Evaluation: >> >>     Now, as to the request to increase the number of real-time signals >>     to 64, this would more than double the currently supported number >>     of signals.  The sigset_t structure, in its present definition, >>     can only support a maximum of 128 signals.  It's a limited resource. >>     Increasing the number of real-time signals to 64 would leave only >>     24 bits remaining in the sigset_t definition for future expansion. >>     We need more wiggle-room than that for future expansion. >> >>     So, when the number of real-time signals is increased, it will only >>     be increased to 32, not 64.  We can increase to 64 only by changing >>     the definition of sigset_t and this breaks binary compatibility, >>     so this can be done only when we move from Solaris 2.x to Solaris 3.x >>     (or whatever the next naming scheme will be called). >> >> Roger Faulkner >> >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From gdamore@Sun.COM Mon Feb 22 12:12:05 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MKC5M8005159 for ; Mon, 22 Feb 2010 12:12:05 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MKC5bl004290 for ; Mon, 22 Feb 2010 12:12:05 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1MKBxxS023272 for ; Mon, 22 Feb 2010 12:11:59 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY900300EP7FZ00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 12:11:59 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY900KX4ERWUDE0@fe-sfbay-09.sun.com>; Mon, 22 Feb 2010 12:11:57 -0800 (PST) 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] In-reply-to: Sender: Garrett.Damore@Sun.COM To: John Plocher Cc: "Roger A. Faulkner" , Jordan.Vaughan@Sun.COM, Bart.Smaalders@Sun.COM, psarc-ext@sac.sfbay.sun.com, Scott.Michael@Sun.COM, Krister.Johansen@Sun.COM Message-id: <4B82E50C.9090100@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1066 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. - Garrett From raf@jurassic.sfbay.sun.com Mon Feb 22 12:25:33 2010 Received: from jurassic.Eng.Sun.COM (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MKPX1L005498 for ; Mon, 22 Feb 2010 12:25:33 -0800 (PST) Received: from rafblade (punchin-raf.SFBay.Sun.COM [10.7.251.247]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with SMTP id o1MKPITh742999; Mon, 22 Feb 2010 12:25:31 -0800 (PST) Message-Id: <201002222025.o1MKPITh742999@jurassic.Eng.Sun.COM> Date: Mon, 22 Feb 2010 15:25:18 -0500 (EST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] To: john.plocher@gmail.com, gdamore@sun.com Cc: Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com, psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: m7BuT+5hHLPa66VW290Dfw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1671 > 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@Sun.COM, Bart.Smaalders@Sun.COM, psarc-ext@sac.sfbay.sun.com, Scott.Michael@Sun.COM, Krister.Johansen@Sun.COM > > 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. > > - Garrett Changing the definition of sigset_t would break all but the most trivial existing applications. Almost everything in the Solaris world would have to be recompiled. Roger From jason.brian.king@gmail.com Mon Feb 22 12:30:24 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MKUOj5005514 for ; Mon, 22 Feb 2010 12:30:24 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MKUNW6006200 for ; Mon, 22 Feb 2010 12:30:23 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1MKQkrK009598 for ; Mon, 22 Feb 2010 20:30:23 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-902975 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 20:30:23 Z Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-14765066 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 20:30:20 Z Received: from mail-fx0-f225.google.com ([209.85.220.225] [209.85.220.225]) by relay1i.sun.com with ESMTP id BT-MMP-33056198 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 20:30:20 Z Received: by fxm25 with SMTP id 25so671225fxm.27 for ; Mon, 22 Feb 2010 12:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=T3teXirgI+Es8NwgLWGSQgMgVFxEZRn7ljFEpt0zol8=; b=b7/2Jzmt55zNmJhQ7meHWmADXu/dmj010uHgmvtFLInpolfhda+WIW3a/CLfWtZ+fV IeY2dkg9GkHhNN/jfgsXKe0V+7yDHTAzQMkSpszA1xm3FHkvWiyGfEzhEjEEGAYfoIyv 2gLILWlbpKGndUZTXngaifmRzuHEdJ6S68tO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LOEYEHtpYqLRrymmfEuTbSDCrPI5wv/y3CzoZZh3LxIGCz0HBpxTVJitbgAgFA7OZv EzOf3k4jPyLp8XpNUbxK7+2obfwztXWfEKZWdC4WsXkJMoeLtBcKdXZobcMzRh/8rpfL dti5wvrAEF2eV6Ww9FlAq+gGBfEpC4ATB+fSE= Sender: jason.brian.king@gmail.com Received: by 10.239.168.68 with SMTP id j4mr313945hbe.136.1266870615598; Mon, 22 Feb 2010 12:30:15 -0800 (PST) In-Reply-To: <4B82E50C.9090100@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> Date: Mon, 22 Feb 2010 14:30:15 -0600 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 260b9b404f31cebb Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: Jason King To: "Garrett D'Amore" Cc: John Plocher , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com X-Antispam: No, score=-1.1/5.0, scanned in 0.085sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o1MKUOj5005514 Status: RO Content-Length: 1649 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 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. From gdamore@sun.com Mon Feb 22 12:42:48 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MKgmxo005716 for ; Mon, 22 Feb 2010 12:42:48 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MKgm8w013031 for ; Mon, 22 Feb 2010 12:42:48 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1MKgh3H025941 for ; Mon, 22 Feb 2010 12:42:43 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY900000G4WEQ00@fe-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 12:42:43 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY9001ORG74ZKD0@fe-sfbay-10.sun.com>; Mon, 22 Feb 2010 12:42:41 -0800 (PST) Date: Mon, 22 Feb 2010 12:42:39 -0800 From: "Garrett D'Amore" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: Sender: Garrett.Damore@sun.com To: Jason King Cc: John Plocher , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com Message-id: <4B82EC3F.6010105@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 2391 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 *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 From iszczesniak@gmail.com Mon Feb 22 13:17:45 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MLHjEO006505 for ; Mon, 22 Feb 2010 13:17:45 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MLHjfZ011807 for ; Mon, 22 Feb 2010 13:17:45 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1MLABAs027113 for ; Mon, 22 Feb 2010 21:17:39 GMT Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-906192 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:17:35 Z Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-20682 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:17:35 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-679831 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:17:35 Z Received: by bwz26 with SMTP id 26so2305388bwz.27 for ; Mon, 22 Feb 2010 13:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MIEN7edALirTycx6rfYevCOzPx/PjRzPes+lFPmbe4Y=; b=Kd9NGZU6bFpTUMnMfmh9BBFB/YRigIuzD4JDz93kkHCq4Wgo7wvKHwr0tmc1hXO5pA nbIicUGLzJfxNx22eE2PmAW49u9k5t4UJjf0Qh0NQabhGTer4uu4HsjH9v78CuwsMSXa hwMg/n8PJUrhol/bfR7MN5ejAEJpsJT+QZD/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tG06mmzUtKWlpU1lAKc6kQbf00Fd9UuaFxyMY5V/SI40hDsfSwYXVLKHNbhhKJq0YM bANn140+jelJE3JDDmLgXkXwR2DRTzGNfum9PC7GceErkH7Mfau19usQdsbu5MNHUXIm CSGm5vQmyJ7frdftOvGLv/gPYsdScMk7I3sdI= Received: by 10.204.155.69 with SMTP id r5mr4829632bkw.0.1266873454108; Mon, 22 Feb 2010 13:17:34 -0800 (PST) In-Reply-To: <4B82DCE6.4050201@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> Date: Mon, 22 Feb 2010 22:17:34 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: "Garrett D'Amore" Cc: "Roger A. Faulkner" , Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com, psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.051sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 841 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 that increasing the number of signals to 64 breaks binary compatibility. 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 be expanded. IMO the case can pass with 64 realtime signals, otherwise I request a derail and full case which explains why again a resource is increased in a half hearted manner. Irek From iszczesniak@gmail.com Mon Feb 22 13:25:30 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MLPUCo006592 for ; Mon, 22 Feb 2010 13:25:30 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MLPUxh016278 for ; Mon, 22 Feb 2010 13:25:30 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1MLF3H5028095 for ; Mon, 22 Feb 2010 21:25:24 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-906735 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:25:24 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-14874134 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:25:24 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-33749806 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:25:24 Z Received: by bwz26 with SMTP id 26so2312233bwz.27 for ; Mon, 22 Feb 2010 13:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wxPkR5EDWpCTasJIuhVVSqMngingOctl1Kby/8s29/Q=; b=dmZYR+Dwo8rQLAA3xrKPY2DCpkOXcKvYRaa0SGi3lBeaSO2x7l7qnS0fT+4MLpRrOF pmUiyHRUDbJewQpDxOKz12A/IyOmcTlfrLTL6enAK98OojVt2z/HZvFw+XyZD7Etx3QL CgvcAnnRlHBjTUO2f/q0bPKdDEL/fJ/XmZRd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ri7O7+vFjZBtYnYjC1uy0Zjh328fe1c/O+B3lE9pjbxifEASFL/jO/v2DOUH9xWK+u otB9CjvnrBrhKJQabHB25CT8GF+MMJ7VxYSWPWsot0aj2IlKDBhesFyDfHDnACa/6IFy oqsP0zXFuvOZMH0N4XZtvdMmdabJaWMuay7Iw= Received: by 10.204.141.69 with SMTP id l5mr2073758bku.64.1266873916797; Mon, 22 Feb 2010 13:25:16 -0800 (PST) In-Reply-To: References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> Date: Mon, 22 Feb 2010 22:25:16 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: Jason King Cc: "Garrett D'Amore" , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 1664 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 *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? No. The POSIX committee defined realtime signals as dynamic resource which may change between system reboots. Applications have to adopt ; yet some require more realtime signals than the minimum required by POSIX (8). IMO (out of experience with IBM and VXWORKS toolkits) the number of realtime signals should match *at least* the number of processors in a system or >= 64. Irek From iszczesniak@gmail.com Mon Feb 22 13:31:14 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MLVEPq006754 for ; Mon, 22 Feb 2010 13:31:14 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MLVD81010857 for ; Mon, 22 Feb 2010 13:31:13 -0800 (PST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1MLKl2h001308 for ; Mon, 22 Feb 2010 21:31:13 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-928385 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:31:13 Z Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-15145124 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:31:13 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-704311 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:31:12 Z Received: by bwz26 with SMTP id 26so2317082bwz.27 for ; Mon, 22 Feb 2010 13:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cDaN4SRE1OhyzMhvzKxA+10DeutHcG58QZAfSH1xhXg=; b=Hgqw7pEN9cZMxs2eQVTiw94+lsBM0IamhB0rYqwa7R7PrzDg37wF3iCj9nCD9ImBIJ 1lhhUgaiwLZg8fe5SGlnJNAv4glMbXnmoQ5BVZ/A48QQsXyFjguCnBrMweEBRSTKJM4u vJBievyUgxIL5f3SSOPs450wZ00cxpDmDBisM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KKlq9QoCJHwjz0BSClYfZYu5x7PSOB5jiTqmwfRvCQG/9Ma020El+ums30pCyvzzlE eL6xBPT9gV8zwCHTYJJDT+OWX2bOLw9iIJpx3QFi5su/6O9XytjHMkEItyyPyYVqJ/NG m6ZAF71neU0scXuouiKL71PkE6+bPoz2EkGXs= Received: by 10.204.24.132 with SMTP id v4mr208744bkb.31.1266874265712; Mon, 22 Feb 2010 13:31:05 -0800 (PST) In-Reply-To: <4B82EC3F.6010105@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> Date: Mon, 22 Feb 2010 22:31:05 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: "Garrett D'Amore" Cc: Jason King , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.082sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 2850 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" >>>> 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. You really want another compile time flag which only works half hearted? Even the stdio 256 workaround was a bad kludge (1) and IMO Solaris should have less of these. 1) I say 'was' as we switched to libast stdio many years ago. libc stdio has long outlived its usefulness beyond basic application needs and passing the VSC test suite. Irek From gdamore@sun.com Mon Feb 22 13:42:46 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MLgkCE006830 for ; Mon, 22 Feb 2010 13:42:46 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MLgjpg025215 for ; Mon, 22 Feb 2010 13:42:45 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1MLgebF001427 for ; Mon, 22 Feb 2010 13:42:40 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY900A00IVH7Q00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 13:42:40 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY9006V3IZ3OO70@fe-sfbay-09.sun.com>; Mon, 22 Feb 2010 13:42:40 -0800 (PST) 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] In-reply-to: Sender: Garrett.Damore@sun.com To: "I. Szczesniak" Cc: Jason King , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com Message-id: <4B82FA4F.3020403@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1255 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 of the opinion that its harder to *reduce* a resource than grow it. We should not design with that escape hatch as a plan. I also confess I don't know why we should feel the need to reserve more than 24 signals, but I also am not privy to the plans and future projects of the kernel group. If they aren't comfortable leaving themselves that few allocated signals, then my inclination is to trust that judgment. Roger, can you elaborate (in private if need be) on the concern of leaving only 24 available signal slots? As far as your request for a derail -- no, I don't think that this is appropriate. However, I am going to request that we go ahead and promote this to a fast track. The amount of discussion we've already had here puts this outside the scope of a self-review. Roger, please mark this as such with a timer set for one week from today (although it can probably be approved at Wednesday's PSARC meeting). - Garrett From johansen@sun.com Mon Feb 22 13:45:46 2010 Received: from jurassic.Eng.Sun.COM (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MLjkWQ006907 for ; Mon, 22 Feb 2010 13:45:46 -0800 (PST) Received: from jurassic.Eng.Sun.COM (localhost [127.0.0.1]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o1MLjjNs757309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 13:45:45 -0800 (PST) Received: (from johansen@localhost) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o1MLjjEQ757298; Mon, 22 Feb 2010 13:45:45 -0800 (PST) X-Authentication-Warning: jurassic.Eng.Sun.COM: johansen set sender to johansen@sun.com using -f Date: Mon, 22 Feb 2010 13:45:45 -0800 From: johansen@sun.com To: "I. Szczesniak" Cc: "Garrett D'Amore" , "Roger A. Faulkner" , Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com, psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <20100222214545.GE701682@eng.sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1309 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 to 64. > > -1 for this case. I did some research on this subject and I disagree > that increasing the number of signals to 64 breaks binary > compatibility. So far, all you have presented is an opinion. Please explain, using actual evidence and technical reasoning, how you came to your conclusion. > 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. Increasing and then decreasing the number of available signals is going to be even more disruptive. How does your proposal ensure binary compatibility? > IMO the case can pass with 64 realtime signals, otherwise I request a > derail and full case which explains why again a resource is increased > in a half hearted manner. That's unreasonable. The number of signals in the sigset_t is an implementation detail. This has already received a superfluous amount of attention, despite it's trivial nature. -j From iszczesniak@gmail.com Mon Feb 22 13:47:18 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MLlIX0006926 for ; Mon, 22 Feb 2010 13:47:18 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1MLlEqg019423 for ; Mon, 22 Feb 2010 13:47:14 -0800 (PST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1MLghS5011805 for ; Mon, 22 Feb 2010 21:47:08 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-929275 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:47:08 Z Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-15173908 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:47:07 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-33209428 for psarc-ext@sac.sfbay.sun.com; Mon, 22 Feb 2010 21:47:07 Z Received: by bwz26 with SMTP id 26so2330320bwz.27 for ; Mon, 22 Feb 2010 13:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Jypy+y3XGcQM2nN4fzBGJ8w37U7cn5pKWGLRkKdLIak=; b=j+Xj3jMJCGCrBSHcRA9OIeCgFZjQhYcwLqhPtSxowZCw3Qp54vF/mpqUcMcpNQDc/O bdn0eqcCLqc0ZAUjnfaEykEF5hgsZKSdQZY5bpGI30jt96xToljmxNZDijghpzNn4oPm aawNgtgQhmUEsR51nHYLIdwiNGqMcZwboa540= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s81U1YETmx9HX7J0PFw+9AfQmOxMMCp/G9hjnFF9hF8Fwy/mhf1enMACSDab5oxQcm h1y6bCcQiSdbP7uzXqaBpe9ckJWzy0ZpEMyFKTFUwIDM2IoYsOkhSqYiMp6/n5nB4S1D tSrfmHB6Y2QuDvs9jSJF+pQ2SDDINnPAyrfQ0= Received: by 10.204.152.153 with SMTP id g25mr3903762bkw.158.1266875219566; Mon, 22 Feb 2010 13:46:59 -0800 (PST) In-Reply-To: <4B82EC3F.6010105@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> Date: Mon, 22 Feb 2010 22:46:59 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: "Garrett D'Amore" Cc: Jason King , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.508sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 2871 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" >>>> 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. The compelling reason is to use more than 32 workers (i.e. processors, threads or processes depending on context and toolkit) in applications which are based on IBM and VXWORKS toolkits. Realtime signals are often used for fast IPC between workers which are either threads or processes and the number of workers is limited by the number of realtime signals. Irek From raf@jurassic.sfbay.sun.com Mon Feb 22 15:03:09 2010 Received: from jurassic.Eng.Sun.COM (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1MN392g009213 for ; Mon, 22 Feb 2010 15:03:09 -0800 (PST) Received: from rafblade (punchin-raf.SFBay.Sun.COM [10.7.251.247]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with SMTP id o1MN37d0771355; Mon, 22 Feb 2010 15:03:07 -0800 (PST) Message-Id: <201002222303.o1MN37d0771355@jurassic.Eng.Sun.COM> Date: Mon, 22 Feb 2010 18:03:07 -0500 (EST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] To: iszczesniak@gmail.com, gdamore@sun.com Cc: jason@ansipunx.net, Krister.Johansen@sun.com, Scott.Michael@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KHKBOU9gd7X7Vvr5uBXySw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1118 > 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@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com > > As far as your request for a derail -- no, I don't think that this is > appropriate. However, I am going to request that we go ahead and > promote this to a fast track. The amount of discussion we've already > had here puts this outside the scope of a self-review. Roger, please > mark this as such with a timer set for one week from today (although it > can probably be approved at Wednesday's PSARC meeting). > > - Garrett Ok. I changed the IAM file to read: Name: increase number of realtime signals Submitter: Roger Faulkner Owner: Roger Faulkner Interest: Status: waiting fast-track 03/01/2010 Exposure: open Comment: Roger From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Feb 23 07:08:39 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1NF8dDM009380 for ; Tue, 23 Feb 2010 07:08:39 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1NF8c3o010668 for ; Tue, 23 Feb 2010 07:08:38 -0800 (PST) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1NEwj22012046 for ; Tue, 23 Feb 2010 15:08:33 GMT Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-849891 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 15:08:29 Z Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-8810892 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 15:08:28 Z Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-22348053 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 15:08:28 Z Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 05ABC63C16F; Tue, 23 Feb 2010 16:08:25 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id AE6907D4015; Tue, 23 Feb 2010 16:08:19 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o1NF8IwV013052; Tue, 23 Feb 2010 16:08:19 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 16:08:18 +0100 Date: Tue, 23 Feb 2010 16:08:18 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: iszczesniak@gmail.com, gdamore@sun.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b83ef62.V0o1er9m/oI1Qeg3%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 23 Feb 2010 15:08:18.0230 (UTC) FILETIME=[07CCB560:01CAB49A] X-Antispam: No, score=0.0/5.0, scanned in 0.440sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 759 "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 be > expanded. Reducing the number of signals will definitely cause a binary incompatibility, so this does not seem to be a valid option. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From olga.kryzhanovska@gmail.com Tue Feb 23 09:51:02 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1NHp2Ju012903 for ; Tue, 23 Feb 2010 09:51:02 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1NHp1V8009924 for ; Tue, 23 Feb 2010 09:51:01 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1NHp1m5002285 for ; Tue, 23 Feb 2010 17:51:01 GMT Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-984045 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 17:49:01 Z Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-345135 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 17:49:00 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-35601998 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 17:49:00 Z Received: by bwz26 with SMTP id 26so3117657bwz.27 for ; Tue, 23 Feb 2010 09:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WunWrujI+Qfsdan35m04hPv5LjG6RgXuVSqRVbBjqhw=; b=ADb2Ki2Gl/JpTdNSOeYQqElLGmvn+ZoqaUx6oLYJqg+T6Ns4cq0gM0/RgA8quLMoN2 cbu1EfvfmdLpi3DlHFQDf89K/vOQGf8cXDndgfdY7GY43wK+5gwZ/tQNvMHABcHP5eS1 FXrPr3C7aXaB4Hgf/beWSDJPJvf0mUNwV3oF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ISxztFIJZnqI/h/bAmw/4pwsCS3JZL/wYDvVnFXf9NgjJ/W7+ttKMfKctcN8HLYPXd 5qdd2W5Hfx5YVYY9V/l/o+Soagv8kg4s71nh/i65FhifQKoWvBc7oCGevmup1pqA9jLX Ql+CxmucnzbELTWq+JbpU5K053cW6JI18nf7U= Received: by 10.204.152.153 with SMTP id g25mr272759bkw.158.1266947334227; Tue, 23 Feb 2010 09:48:54 -0800 (PST) In-Reply-To: <4b83ef62.V0o1er9m/oI1Qeg3%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4b83ef62.V0o1er9m/oI1Qeg3%Joerg.Schilling@fokus.fraunhofer.de> Date: Tue, 23 Feb 2010 18:48:54 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= To: Joerg Schilling Cc: iszczesniak@gmail.com, gdamore@sun.com, Krister.Johansen@sun.com, Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.250sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o1NHp2Ju012903 Status: RO Content-Length: 1898 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 out of frustration with the POSIX real time signal implementation in Solaris. 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. Olga On Tue, Feb 23, 2010 at 4:08 PM, Joerg Schilling wrote: > "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 be >> expanded. > > Reducing the number of signals will definitely cause a binary incompatibility, > so this does not seem to be a valid option. > > Jörg > > -- > EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin > js@cs.tu-berlin.de (uni) > joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From olga.kryzhanovska@gmail.com Tue Feb 23 09:59:05 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1NHx5Ti013447 for ; Tue, 23 Feb 2010 09:59:05 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1NHx5LR023582 for ; Tue, 23 Feb 2010 09:59:05 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1NHo5xJ001959 for ; Tue, 23 Feb 2010 17:59:04 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-984714 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 17:59:04 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-17481492 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 17:59:04 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-36216459 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 17:59:04 Z Received: by bwz26 with SMTP id 26so3129219bwz.27 for ; Tue, 23 Feb 2010 09:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MT10Er3rAoiuLyQeVCfgN8JkwrMJeveZau6JGKTnOYg=; b=jM4XPPLyKAK2TI7CP6MJnHszs/lUy3UaKYmwxTX/ONYOBId2gvxEVy7GAIPRXI9B7P JULV7YB09f9qqJklUjhD8/JofZKpSt2tLABcgS8g8pNYpoJEl1An8SgDrwWsiK/WZFY0 qPJ7k6aEFcVlE/LY0ZwMpL2azkjQWAhVHMqzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e+2dByKSUPVlK+jd1aehr8dZtb03ftEEDl+TOKyUIuBerekSfxrGjNy3g/i/Fm/z3B Y7ORLCptPzjMYJAxhUxFMdhWvbQ0V4DuX/KgoFEt/ZrrC27DQZCAQPYdZ1BgJaY5qC5/ /l3LgAW0IelE/1eTp10zfid9x/d3tLuYFgbwI= Received: by 10.204.143.129 with SMTP id v1mr1567292bku.167.1266947940210; Tue, 23 Feb 2010 09:59:00 -0800 (PST) In-Reply-To: <4B82DCE6.4050201@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> Date: Tue, 23 Feb 2010 18:59:00 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= To: "Garrett D'Amore" Cc: "Roger A. Faulkner" , Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com, psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.079sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 3099 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 free signal slots remain. Is that observation right? Olga 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. > > 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 this point. > > -- Garrett > >> 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 32 or 64 depending on architecture, AIX supports 111. >> >> This affects Solaris directly in that the Linux zone >> provided by Solaris cannot support Linux applications >> that use more than 8 realtime signals. See the bug report: >> 6820733 lack of realtime signals causes Linux application >> in BrandZ to fail >> which is a duplicate of the more general bug report: >> 6820737 Solaris needs to increase the number of realtime signals >> for platform parity >> >> This case proposes to increase the number of realtime signals >> supported by Solaris from 8 to 32. >> >> Why not just go to 64, one might ask? >> The reason is contained in the 6820737 bug report's Evaluation: >> >> Now, as to the request to increase the number of real-time signals >> to 64, this would more than double the currently supported number >> of signals. The sigset_t structure, in its present definition, >> can only support a maximum of 128 signals. It's a limited resource. >> Increasing the number of real-time signals to 64 would leave only >> 24 bits remaining in the sigset_t definition for future expansion. >> We need more wiggle-room than that for future expansion. >> >> So, when the number of real-time signals is increased, it will only >> be increased to 32, not 64. We can increase to 64 only by changing >> the definition of sigset_t and this breaks binary compatibility, >> so this can be done only when we move from Solaris 2.x to Solaris 3.x >> (or whatever the next naming scheme will be called). >> >> Roger Faulkner >> >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From olga.kryzhanovska@gmail.com Tue Feb 23 10:01:08 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1NI18Ff013533 for ; Tue, 23 Feb 2010 10:01:08 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1NI174o016815 for ; Tue, 23 Feb 2010 10:01:08 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1NHwKAW004375 for ; Tue, 23 Feb 2010 18:01:07 GMT Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-98462 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 18:01:07 Z Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-373566 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 18:01:07 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-35631172 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 18:01:07 Z Received: by bwz26 with SMTP id 26so3131644bwz.27 for ; Tue, 23 Feb 2010 10:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=X/CdCoroJS2oz3ODpl62tC3cDgxz0Ztz0LXDB0Ojhl8=; b=SkicqeEcaQ0wMPl5TBdmnN3ZAxAPBONzMCTnkLsIg1pGaDHv6bgjc4G4UK0ZnT8p5y i2B3HpDrBBMXYYyi4B0JYUvPb5rXYw5JAbsUg572TmHcOQ6kzmnrnvByoEk66s8V53qO LXhk+xYcWHtuvLmpz/tmg2OnfaXHQmJNZ+VjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fv6uYn3+p0Wdd8dpfi11SZObg6JgVO+6pU6bVQmwzy4jZPWfuWPLpJzoDAwvlk70V+ 5ZRW259D7yRZdrcnYG6XchUyr0DNqMAmufuB1PLg7iTK2bhUCzle2LDzlY+3m6am5mfK J933WQfgW0HweNy/5bjUZEdMsQRyC6QxnoIzI= Received: by 10.204.10.151 with SMTP id p23mr1165135bkp.80.1266948065402; Tue, 23 Feb 2010 10:01:05 -0800 (PST) In-Reply-To: <201002222025.o1MKPITh742999@jurassic.Eng.Sun.COM> References: <201002222025.o1MKPITh742999@jurassic.Eng.Sun.COM> Date: Tue, 23 Feb 2010 19:01:05 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= To: "Roger A. Faulkner" Cc: john.plocher@gmail.com, gdamore@sun.com, Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com, psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.076sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 2382 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. Olga On Mon, Feb 22, 2010 at 9:25 PM, Roger A. Faulkner wrote: > >> 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@Sun.COM, > Bart.Smaalders@Sun.COM, psarc-ext@sac.sfbay.sun.com, Scott.Michael@Sun.COM, > Krister.Johansen@Sun.COM >> >> 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. >> >> - Garrett > > Changing the definition of sigset_t would break all but the > most trivial existing applications. Almost everything in the > Solaris world would have to be recompiled. > > Roger > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From olga.kryzhanovska@gmail.com Tue Feb 23 10:11:10 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1NIBANe013807 for ; Tue, 23 Feb 2010 10:11:10 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1NIBARr023089 for ; Tue, 23 Feb 2010 10:11:10 -0800 (PST) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1NI09mB005202 for ; Tue, 23 Feb 2010 18:11:09 GMT Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay41i.sun.com with ESMTP id BT-MMP-919878 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 18:11:09 Z Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-10744521 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 18:11:09 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay4i.sun.com with ESMTP id BT-MMP-22867541 for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 18:11:08 Z Received: by bwz26 with SMTP id 26so3141867bwz.27 for ; Tue, 23 Feb 2010 10:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ue25WIXlZ5EFvfeBGSWmYKHq/uE5BGinK++GRTUKQes=; b=vuy6nluDmWUh2mzUDaE2ha9lBtpd0TZZlUuqFgXd7JhI80N20MVoyTxoEaYxHWI8ET bpo12uvs571OCjkJvJyErmJNEbKP6eRVEyuvMJs+LUsT3KbOw0flbmgOcTACBhY0vG96 M/jCp5DFaxy5aFti8HNJ5+o4qt0nFUEQdcyus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ugPSQB9JMTGnGi/USpEgCno9+YWRh1/WSXjRtYPzvz3Q4E+XQ3ing1475soa5RL+r6 ZncXiBcSKxGOoTX+FqfwIxtdBpruhUPnO/L6bZSTcPgg7O4RmGAn4QB9ZIq/U3O08sR4 di0XNJekRONSTObxpSQHXrmgSd7or31G3jsTA= Received: by 10.204.143.129 with SMTP id v1mr1579379bku.167.1266948612280; Tue, 23 Feb 2010 10:10:12 -0800 (PST) In-Reply-To: <4B82EC3F.6010105@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> Date: Tue, 23 Feb 2010 19:10:12 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= To: "Garrett D'Amore" Cc: Jason King , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.091sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 3565 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? Olga 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" >>>> 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@opensolaris.org > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanovska@gmail.com \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` From gdamore@sun.com Tue Feb 23 11:28:03 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1NJS3wr015025 for ; Tue, 23 Feb 2010 11:28:03 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1NJS0qS019449 for ; Tue, 23 Feb 2010 11:28:03 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1NJRtE7001282 for ; Tue, 23 Feb 2010 11:27:55 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; format=flowed; charset=UTF-8 Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYB00G007EBYD00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 23 Feb 2010 11:27:55 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYB00M9O7EHSK40@fe-sfbay-09.sun.com>; Tue, 23 Feb 2010 11:27:54 -0800 (PST) Date: Tue, 23 Feb 2010 11:27:53 -0800 From: "Garrett D'Amore" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: Sender: Garrett.Damore@sun.com To: =?UTF-8?B?0L7Qu9GM0LPQsCDQutGA0YvQttCw0L3QvtCy0YHQutCw0Y8=?= Cc: Jason King , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com Message-id: <4B842C39.3060905@sun.com> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 4102 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 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" >>>>> 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@opensolaris.org >> >> > > > From Nicolas.Williams@sun.com Tue Feb 23 12:28:54 2010 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1NKSsnc016361 for ; Tue, 23 Feb 2010 12:28:54 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o1NKDpGk007581; Tue, 23 Feb 2010 14:13:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o1NKDpnS007580; Tue, 23 Feb 2010 14:13:51 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 23 Feb 2010 14:13:51 -0600 From: Nicolas Williams To: "Garrett D'Amore" Cc: =?utf-8?B?0L7Qu9GM0LPQsCDQutGA0YvQttCw0L3QvtCy0YHQutCw0Y8=?= , Jason King , Krister.Johansen@sun.com, Scott.Michael@sun.com, "Roger A. Faulkner" , Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <20100223201350.GA1061@Sun.COM> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> <4B842C39.3060905@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B842C39.3060905@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 900 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 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. There could be a kernel compile-time maximum that could be set to 64 for now, and if later we need more than the remaining 24 signals we could decrease that maximum. Nico -- From raf@jurassic.sfbay.sun.com Tue Feb 23 23:09:31 2010 Received: from jurassic.Eng.Sun.COM (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1O79Vj9028105 for ; Tue, 23 Feb 2010 23:09:31 -0800 (PST) Received: from rafblade (punchin-raf.SFBay.Sun.COM [10.7.251.247]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with SMTP id o1O79LSB353076; Tue, 23 Feb 2010 23:09:21 -0800 (PST) Message-Id: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> Date: Wed, 24 Feb 2010 02:09:21 -0500 (EST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] To: psarc-ext@sac.sfbay.sun.com Cc: Scott.Michael@sun.com, krister.johansen@sun.com, bart.smaalders@sun.com, jordan.vaughan@sun.com, gdamore@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, Nicolas.Williams@sun.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y/MjOv25kme7UckLRGPlLw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 sun4u sparc Status: RO Content-Length: 4646 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/containers: I've already added code to the S10 brand to map/constrain processes running in an S10 container to see only 8 realtime signals. It works perfectly so long as such processes interact only with other processes in the same container. We have to rely on good judgement for no one to send an extended realtime signal to such a process from the global zone (such a signal will cause the process running in the S10 zone to die). 3. There will be no special compilation/runtime environment. The signal number space is a system-wide property. There will be no per-process variation on this. (The S10 zone represents a whole system in this sense.) 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. 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. =================== 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?) I proposed the number be 32 because it seemed to me to be a reasonable use of the limited number space in a sigset_t, which has a capacity of 128 signal numbers (and this can't be changed): typedef struct { unsigned int __sigbits[4]; } sigset_t; Solaris started out with 31 signals (from SVR3 and SunOS4.x). It has grown by 9 since then with these: #define SIGWAITING 32 /* reserved signal no longer used by threading code */ #define SIGLWP 33 /* reserved signal no longer used by threading code */ #define SIGFREEZE 34 /* special signal used by CPR */ #define SIGTHAW 35 /* special signal used by CPR */ #define SIGCANCEL 36 /* reserved signal for thread cancellation */ #define SIGLOST 37 /* resource lost (eg, record-lock lost) */ #define SIGXRES 38 /* resource control exceeded */ #define SIGJVM1 39 /* reserved signal for Java Virtual Machine */ #define SIGJVM2 40 /* reserved signal for Java Virtual Machine */ plus the 8 previous realtime signals, for a total of 48. Increasing the number of realtime signals to 32 brings us to 72, leaving 56 available, which seems like a comfortable margin to me. Increasing the number of realtime signals to 64 would bring us to 104, leaving 24 available, which seems like too few for a comfortable margin to me. I admit, it's a judgement call. I have to question Irek Szczesniak's justification of 64 RT signals based on the experience with IBM and VXWORKS toolkits: The compelling reason is to use more than 32 workers (i.e. processors, threads or processes depending on context and toolkit) in applications which are based on IBM and VXWORKS toolkits. Realtime signals are often used for fast IPC between workers which are either threads or processes and the number of workers is limited by the number of realtime signals. I admit to not being familiar with the mentioned toolkits, but if signals are being used for a fast IPC between workers, then it must be done via: pthread_kill(tid, sig); or: kill(pid, sig); both of which interfaces use an identifier (tid or pid) for the target worker. Given this, there is no need for a further discriminate based on the signal number. Or, if the target process is multithreaded and the signal number is used to designate an internal worker of the target process, then this signal interface could be used: sigqueue(pid_t pid, int signo, const union sigval value); and the sigval integer value (a 32-bit int) could be used to discriminate up to 2 billion values (a lot more than 64). I find it hard to believe that more than 32 realtime signal numbers is ever really needed, and if it is then you would need a lot more than 64. =================== Roger Faulkner From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Feb 24 01:29:47 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1O9TlRU015900 for ; Wed, 24 Feb 2010 01:29:47 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1O9TkGX007724 for ; Wed, 24 Feb 2010 01:29:46 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1O9Tk9v003882 for ; Wed, 24 Feb 2010 09:29:46 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-1028907 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 09:27:46 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-18597971 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 09:27:44 Z Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-37258316 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 09:27:44 Z Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id BCA3C6F059C; Wed, 24 Feb 2010 10:27:42 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id A56DA6F057F; Wed, 24 Feb 2010 10:27:40 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o1O9ReVr015631; Wed, 24 Feb 2010 10:27:41 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 10:27:40 +0100 Date: Wed, 24 Feb 2010 10:27:37 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: olga.kryzhanovska@gmail.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, iszczesniak@gmail.com, gdamore@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b84f109.R33Bi1+1dZppD0OD%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4b83ef62.V0o1er9m/oI1Qeg3%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 24 Feb 2010 09:27:40.0462 (UTC) FILETIME=[9C5A8CE0:01CAB533] X-Antispam: No, score=-1.1/5.0, scanned in 1.452sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 2492 ????? ???????????? 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 time signals > work. Fast guesses do not help and you demonstrated several times in the past already that you failed this way... On the other side, you support contradicting arguments: - You claim that people _need_ more RT signals - You claim that people will be able to write code that dynamically adopts to a lower number of RT signals. This proves that the software in question would be able to deal with less RT signals. So wy do you need more RT signals at all? I am still missing any argument from the people who like to extend the number of RT signals. Singnals are not a fast mechanism, so it seems to be wise to avoid them. I remember that I wrote an "event count" mechanism for the Solaris kernel in 1995 in order to be able to have an extremely fast process synchronization mechanism. This was done because signals are way too slow... 1.5 years later, Sun came up with user space mutexes that offer a similar speed to what I implemented using event counts. 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. If you like to let a process or thread block until an event occurs, you need user space mutexes. If you like to send asynchronous notifications to the process you need a single singnal and if you like to signal distinct reasons for that asynchronous event, you may use a piece of process/thread specific shared memory that offers even more space for descriptions than a single signal number does. The only remaining argument is software compiled for Linux that asumes that there are more RT signals. Even here, you gave an argument against real a demand for more RT signals: The number of RT signals is dynamic, so a program that does not properly deal with a lower number of RT signals could be called "buggy". Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Feb 24 01:38:02 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1O9c1BI015935 for ; Wed, 24 Feb 2010 01:38:02 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1O9c1Ll022357 for ; Wed, 24 Feb 2010 01:38:01 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1O9VFMe015577 for ; Wed, 24 Feb 2010 09:38:01 GMT Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-893749 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 09:38:00 Z Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-9905392 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 09:38:00 Z Received: from relay04-haj2.antispameurope.com ([83.246.65.54] [83.246.65.54]) by relay4i.sun.com with ESMTP id BT-MMP-24216399 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 09:38:00 Z Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id B22175EC3E8; Wed, 24 Feb 2010 10:37:58 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id D80895EC1B0; Wed, 24 Feb 2010 10:37:56 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o1O9bvnA015904; Wed, 24 Feb 2010 10:37:57 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 10:37:56 +0100 Date: Wed, 24 Feb 2010 10:37:57 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: olga.kryzhanovska@gmail.com, gdamore@sun.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b84f375.QsPn5ST6hbRiWbDB%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 24 Feb 2010 09:37:56.0883 (UTC) FILETIME=[0BC4EE30:01CAB535] X-Antispam: No, score=0.0/5.0, scanned in 0.074sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 1313 ????? ???????????? 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? signal()/sigaction()/.... do not accept more than NSIG > 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? /bin/getconf RTSIG_MAX always returns 8 on Solaris. getconf does not call sysconf() for this property. Please first verify that there is a real need for more RT signals before looking for a solution. Linux offers 32 RT signals and the only need I see is to support 32 for Linux compatibility. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From casper@holland.sun.com Wed Feb 24 02:51:43 2010 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OApgfE016826 for ; Wed, 24 Feb 2010 02:51:42 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1OApZBr011848; Wed, 24 Feb 2010 10:51:35 GMT Message-Id: <201002241051.o1OApZBr011848@dm-holland-02.uk.sun.com> From: Casper.Dik@sun.com To: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= cc: "Roger A. Faulkner" , john.plocher@gmail.com, gdamore@sun.com, Jordan.Vaughan@sun.com, Bart.Smaalders@sun.com, psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-Reply-To: References: <201002222025.o1MKPITh742999@jurassic.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Feb 2010 11:51:35 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 244 >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 From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Feb 24 04:30:17 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OCUHDi018282 for ; Wed, 24 Feb 2010 04:30:17 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1OCUHUH026997 for ; Wed, 24 Feb 2010 04:30:17 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1OCRsC2015678 for ; Wed, 24 Feb 2010 12:30:11 GMT Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-903297 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 12:30:09 Z Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-11952486 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 12:30:07 Z Received: from relay04-haj2.antispameurope.com ([83.246.65.54] [83.246.65.54]) by relay4i.sun.com with ESMTP id BT-MMP-3622336 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 12:30:07 Z Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 41AB65EC0BD; Wed, 24 Feb 2010 13:30:04 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id E74375EC15D; Wed, 24 Feb 2010 13:29:59 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o1OCTxOp021217; Wed, 24 Feb 2010 13:29:59 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 13:29:58 +0100 Date: Wed, 24 Feb 2010 13:29:59 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com Cc: Scott.Michael@sun.com, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com, krister.johansen@sun.com, jordan.vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, gdamore@sun.com, bart.smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b851bc7.LeTxKeAPXnowrdYo%Joerg.Schilling@fokus.fraunhofer.de> References: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> In-Reply-To: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 24 Feb 2010 12:29:58.0962 (UTC) FILETIME=[14353120:01CAB54D] X-Antispam: No, score=0.0/5.0, scanned in 1.218sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 601 "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@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From iszczesniak@gmail.com Wed Feb 24 05:19:03 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1ODJ3uc019011 for ; Wed, 24 Feb 2010 05:19:03 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1ODJ3cP003428 for ; Wed, 24 Feb 2010 05:19:03 -0800 (PST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1ODHq2w009734 for ; Wed, 24 Feb 2010 13:18:57 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-1063836 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:18:57 Z Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-19017542 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:18:57 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-38118902 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:18:57 Z Received: by bwz26 with SMTP id 26so3851446bwz.27 for ; Wed, 24 Feb 2010 05:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=k7zVNDewK2sfzrhi3WPaVl2WMCfVbfKcozkZaOpwOwg=; b=CAUn/8Wmh0D6TA1ubzb/8dRumW5+ts5PZaZRJwZXiLDQze1ykEUbkyAt4Sen6PlNhJ 30vZTbN0SmHlquG9aj82bOXu+/wS+bSs+F4J+XwvAVihxf5btKQymxvP/9dqgBbjgy4r z+QHbxElIM7U/rb/gpVzOjAoPdGYuQKD+L2WI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bSgw9FAB7fS2as8iD1nl4kTfn/OYGTVpKipECIzqMf0W8Pr4aKQyDPChbP33myLYSo EW//RZRcuH7FVhtxha6qz/OBrn1cQt61O8C5QSCIpAa3It6Hj0g8sr/Lg//x8eu5U7QC MlXxgcjfowxWVCltruhPd31g7BxaroCYR/G4s= Received: by 10.204.132.207 with SMTP id c15mr452422bkt.102.1267017532800; Wed, 24 Feb 2010 05:18:52 -0800 (PST) In-Reply-To: <4b84f375.QsPn5ST6hbRiWbDB%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> <4b84f375.QsPn5ST6hbRiWbDB%Joerg.Schilling@fokus.fraunhofer.de> Date: Wed, 24 Feb 2010 14:18:52 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: Joerg Schilling Cc: olga.kryzhanovska@gmail.com, gdamore@sun.com, Krister.Johansen@sun.com, Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, psarc-ext@sac.sfbay.sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.067sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 1716 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: >> 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? > > signal()/sigaction()/.... do not accept more than NSIG > >> 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? > > /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 > > Please first verify that there is a real need for more RT signals before > looking for a solution. My company does have real need for more RT signals to migrate away from AIX. If Solaris engineering sees itself unable to jump over its conservative shadow, i.e. is unable to bump the value to 64 than its fine for me, there are two alternative operating systems which meet this requirement. > Linux offers 32 RT signals and the only need I see is to support 32 for > Linux compatibility. Linux is not the only operating system which should be used as source of Opensolaris project "copy-innovations". Do some research. Irek From iszczesniak@gmail.com Wed Feb 24 05:31:57 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1ODVvHV019134 for ; Wed, 24 Feb 2010 05:31:57 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1ODVuWW008059 for ; Wed, 24 Feb 2010 05:31:57 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1ODMeMB025944 for ; Wed, 24 Feb 2010 13:31:51 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-1043495 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:31:51 Z Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-19306400 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:31:51 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-5094395 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:31:51 Z Received: by bwz26 with SMTP id 26so3861826bwz.27 for ; Wed, 24 Feb 2010 05:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AN/7YI/LkaOec9VNrmkpUsN3bDdWaISQEgVD5ZY/RJc=; b=WQRoYU7TTmtTsb++9QFTDQ+Q09Saggi4/asEN19L5yJ7gYRDUimU9dMGjwrfj1EawQ BBsmyR2+z0gh9PIx+92JpG0Bl8lVSBjMXlJjezRX2af93yKQsxLTAiQEav6/rsPnr7C1 mstLsbdHR5aFNlaOKdvLE556Z0X4+QYpCwz0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uwAS0n+QWg3Opa37rfaAetSpfzERa8y08O68siQRnEQMjtPb4LidyzkGOfVg0ZxhEm YnY9aWAHKuz1vf9zF1zOh6LR1uSrUqqiWVHoMYCXWI0mT4PtG2ODANUc5BJYOYZDFcQG z5e7m16i/4QhTrozrht7HHpxNbdrLGlLjvld0= Received: by 10.204.20.17 with SMTP id d17mr2626108bkb.195.1267018307216; Wed, 24 Feb 2010 05:31:47 -0800 (PST) In-Reply-To: <4b84f109.R33Bi1+1dZppD0OD%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4b83ef62.V0o1er9m/oI1Qeg3%Joerg.Schilling@fokus.fraunhofer.de> <4b84f109.R33Bi1+1dZppD0OD%Joerg.Schilling@fokus.fraunhofer.de> Date: Wed, 24 Feb 2010 14:31:47 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: Joerg Schilling Cc: olga.kryzhanovska@gmail.com, Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, Bart.Smaalders@sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.085sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 3179 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 same >> operating system. I sounds you don't know how POSIX real time signals >> work. > > Fast guesses do not help and you demonstrated several times in the past > already that you failed this way... > > On the other side, you support contradicting arguments: > > - You claim that people _need_ more RT signals Yes, my company does have such a need. > > - You claim that people will be able to write code that dynamically > adopts to a lower number of RT signals. This proves that the software > in question would be able to deal with less RT signals. So wy do you > need more RT signals at all? Quoting myself: > The compelling reason is to use more than 32 workers (i.e. processors, > threads or processes depending on context and toolkit) in applications > which are based on IBM and VXWORKS toolkits. Realtime signals are > often used for fast IPC between workers which are either threads or > processes and the number of workers is limited by the number of > realtime signals. > I am still missing any argument from the people who like to extend the number > of RT signals. > > Singnals are not a fast mechanism, so it seems to be wise to avoid them. I > remember that I wrote an "event count" mechanism for the Solaris kernel in > 1995 in order to be able to have an extremely fast process synchronization > mechanism. This was done because signals are way too slow... 1.5 years later, > Sun came up with user space mutexes that offer a similar speed to what I > implemented using event counts. > > 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 signals beyond the name itself. Do some research before you send the next mail in this ARC case. > If you like to let a process or thread block until an event occurs, you need > user space mutexes. > > If you like to send asynchronous notifications to the process you need a single > singnal and if you like to signal distinct reasons for that asynchronous event, > you may use a piece of process/thread specific shared memory that offers even > more space for descriptions than a single signal number does. > > The only remaining argument is software compiled for Linux that asumes that > there are more RT signals. Even here, you gave an argument against real a demand > for more RT signals: The number of RT signals is dynamic, so a program that does > not properly deal with a lower number of RT signals could be called "buggy". Not buggy, it will just be restricted to a lower number of worker threads/processes. The current value of RTSIG_MAX is a bit low now that Sun sells machines with 128 processors. Irek From Darren.Moffat@Sun.COM Wed Feb 24 05:50:09 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1ODo9QV019190 for ; Wed, 24 Feb 2010 05:50:09 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1ODo8cJ028758 for ; Wed, 24 Feb 2010 05:50:09 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1ODo36c001442 for ; Wed, 24 Feb 2010 13:50:03 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYC00H00M2RUP00@fe-emea-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:49:53 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYC00EYTMEYYF20@fe-emea-10.sun.com>; Wed, 24 Feb 2010 13:49:47 +0000 (GMT) Date: Wed, 24 Feb 2010 13:49:46 +0000 From: Darren J Moffat Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: Sender: Darren.Moffat@Sun.COM To: "I. Szczesniak" Cc: Joerg Schilling , Krister.Johansen@Sun.COM, gdamore@Sun.COM, Scott.Michael@Sun.COM, raf@jurassic.sfbay.sun.com, Bart.Smaalders@Sun.COM, Jordan.Vaughan@Sun.COM, psarc-ext@sac.sfbay.sun.com Message-id: <4B852E7A.7040505@Sun.COM> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> <4b84f375.QsPn5ST6hbRiWbDB%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1080 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 how you ask getconf(1) for the information. If like your example you asked for RTSIG_MAX then you are correct that a sysconfig(2) call is made. On the other if you ask getconf(1) for _POSIX_RTSIG_MAX then no sysconfig(2) call is made: portellen:pts/26$ truss -t sysconfig getconf RTSIG_MAX sysconfig(_CONFIG_PAGESIZE) = 4096 sysconfig(_CONFIG_RTSIG_MAX) = 8 8 versus portellen:pts/26$ truss -t sysconfig getconf _POSIX_RTSIG_MAX sysconfig(_CONFIG_PAGESIZE) = 4096 8 This is because getconf has some internal tables it doesn't call sysconfig(2) for. The above was on onnv_132 with $SHELL as /usr/bin/zsh, if ksh93 is used then getconf is a shell built in but the same behaviour is seen because it eventually calls out to /bin/getconf anyway. -- Darren J Moffat From iszczesniak@gmail.com Wed Feb 24 05:50:36 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1ODoZr2019202 for ; Wed, 24 Feb 2010 05:50:35 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1ODoZMj015189 for ; Wed, 24 Feb 2010 05:50:35 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1ODcIgE010806 for ; Wed, 24 Feb 2010 13:50:34 GMT Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-1051169 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:48:34 Z Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-17109081 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:48:34 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-5134115 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 13:48:34 Z Received: by bwz26 with SMTP id 26so3876074bwz.27 for ; Wed, 24 Feb 2010 05:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=v4L6+JgSxS2oOtvEWaxga3zcTpi0NpTOPX66qqDSd5I=; b=ZX3qz5Nq1qhuMPDwkq31UBbYAFL4OY5ZcKm52HAdnLiMx2ILmO0XDaSRDKwE+vj5uy +BKq2m19eAlgDbEgr4SLVL20TTVY/JYY7Ej2XWWxNI+1Yh7s7yKpUMKQDXVLGJtsGybX r1j0/MU9a9NXNMuEeCo9EeM7zQDxDWrZ91iWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tTYdu/U6bmQyS1Rqcbgvg+l0f5HHN+dqYO2QJ8VsF4LS2yGaYOAKawF43Ojg0bNWrE U+mlKPD0CvgmVBSjCkVfZ7wSP+WMYes7ITm++2/mkTnYIQq5ljQ/bDU136VvXUclucbm AlSsXNGa/vFaWuJkR6uJYMo41tY5/Faq3M7hw= Received: by 10.204.48.209 with SMTP id s17mr4979072bkf.88.1267019309041; Wed, 24 Feb 2010 05:48:29 -0800 (PST) In-Reply-To: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> References: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> Date: Wed, 24 Feb 2010 14:48:28 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, krister.johansen@sun.com, bart.smaalders@sun.com, jordan.vaughan@sun.com, gdamore@sun.com, john.plocher@gmail.com, jason@ansipunx.net, Nicolas.Williams@sun.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.119sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 5485 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 number > space to use for realtime signal numbers. > > 2. S10 brand/containers: I've already added code to the S10 brand > to map/constrain processes running in an S10 container to see > only 8 realtime signals. It works perfectly so long as such > processes interact only with other processes in the same container. > We have to rely on good judgement for no one to send an extended > realtime signal to such a process from the global zone (such a > signal will cause the process running in the S10 zone to die). > > 3. There will be no special compilation/runtime environment. > The signal number space is a system-wide property. > There will be no per-process variation on this. > (The S10 zone represents a whole system in this sense.) > > 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. > > 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. > > =================== > > 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?) > > I proposed the number be 32 because it seemed to me to be a reasonable > use of the limited number space in a sigset_t, which has a capacity > of 128 signal numbers (and this can't be changed): > > typedef struct { > unsigned int __sigbits[4]; > } sigset_t; > > Solaris started out with 31 signals (from SVR3 and SunOS4.x). > It has grown by 9 since then with these: > > #define SIGWAITING 32 /* reserved signal no longer used by threading code */ > #define SIGLWP 33 /* reserved signal no longer used by threading code */ > #define SIGFREEZE 34 /* special signal used by CPR */ > #define SIGTHAW 35 /* special signal used by CPR */ > #define SIGCANCEL 36 /* reserved signal for thread cancellation */ > #define SIGLOST 37 /* resource lost (eg, record-lock lost) */ > #define SIGXRES 38 /* resource control exceeded */ > #define SIGJVM1 39 /* reserved signal for Java Virtual Machine */ > #define SIGJVM2 40 /* reserved signal for Java Virtual Machine */ > > plus the 8 previous realtime signals, for a total of 48. > Increasing the number of realtime signals to 32 brings us to 72, > leaving 56 available, which seems like a comfortable margin to me. > > Increasing the number of realtime signals to 64 would bring us to 104, > leaving 24 available, which seems like too few for a comfortable margin > to me. I admit, it's a judgement call. > > I have to question Irek Szczesniak's justification of 64 RT signals > based on the experience with IBM and VXWORKS toolkits: > > The compelling reason is to use more than 32 workers (i.e. processors, > threads or processes depending on context and toolkit) in applications > which are based on IBM and VXWORKS toolkits. Realtime signals are > often used for fast IPC between workers which are either threads or > processes and the number of workers is limited by the number of > realtime signals. > > I admit to not being familiar with the mentioned toolkits, but if > signals are being used for a fast IPC between workers, then it > must be done via: > pthread_kill(tid, sig); > or: > kill(pid, sig); > both of which interfaces use an identifier (tid or pid) for the > target worker. Given this, there is no need for a further > discriminate based on the signal number. Different signals are used for different purposes but may target the same thread. > > Or, if the target process is multithreaded and the signal number > is used to designate an internal worker of the target process, > then this signal interface could be used: > sigqueue(pid_t pid, int signo, const union sigval value); > and the sigval integer value (a 32-bit int) could be used > to discriminate up to 2 billion values (a lot more than 64). sigqueue() is not available in shells, perl or other languages nor will it help if the toolkit and not the application controls the signals, i.e. your hooks are called by the toolkit and do not receive the sigval value. > 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 signals are used as extended USR signals with special delivery gurantees. > 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. Irek From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Feb 24 07:11:09 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OFB8ZZ020433 for ; Wed, 24 Feb 2010 07:11:09 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1OFB8Ax021218 for ; Wed, 24 Feb 2010 07:11:08 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1OF2Ade010921 for ; Wed, 24 Feb 2010 15:11:07 GMT Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-919403 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:11:06 Z Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-10520467 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:11:06 Z Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-24175369 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:11:06 Z Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 1551663C19E; Wed, 24 Feb 2010 16:11:04 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 07BB363C193; Wed, 24 Feb 2010 16:11:02 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o1OFB1h8025497; Wed, 24 Feb 2010 16:11:01 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 16:11:01 +0100 Date: Wed, 24 Feb 2010 16:10:58 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: iszczesniak@gmail.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, olga.kryzhanovska@gmail.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b854182./0eFCSBAdY04Jc36%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4B82E50C.9090100@sun.com> <4B82EC3F.6010105@sun.com> <4b84f375.QsPn5ST6hbRiWbDB%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 24 Feb 2010 15:11:01.0429 (UTC) FILETIME=[937CA650:01CAB563] X-Antispam: No, score=-0.2/5.0, scanned in 0.120sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 1387 "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, you don't make reseach :-( I of course checked getconf..... but sometimes it is possible to overlook things in special if the source looks as if it definitely does not call sysconf(). > > Please first verify that there is a real need for more RT signals before > > looking for a solution. > > My company does have real need for more RT signals to migrate away > from AIX. If Solaris engineering sees itself unable to jump over its > conservative shadow, i.e. is unable to bump the value to 64 than its > fine for me, there are two alternative operating systems which meet > this requirement. Well if you really have such a need, it should be possible for you to explaint us _why_ you believe that you need so many RT signal instead of claiming that you need them. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Feb 24 07:13:03 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OFD3Kl020466 for ; Wed, 24 Feb 2010 07:13:03 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1OFD3gt021982 for ; Wed, 24 Feb 2010 07:13:03 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1OF8qxm020730 for ; Wed, 24 Feb 2010 15:12:57 GMT Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-914969 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:12:57 Z Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-10346144 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:12:56 Z Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-26190513 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:12:51 Z Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 8836963C0C4; Wed, 24 Feb 2010 16:12:48 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 048F163C097; Wed, 24 Feb 2010 16:12:45 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o1OFCkjr025520; Wed, 24 Feb 2010 16:12:46 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 16:12:45 +0100 Date: Wed, 24 Feb 2010 16:12:46 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: iszczesniak@gmail.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, olga.kryzhanovska@gmail.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b8541ee.Kk16RRVN31dRrob3%Joerg.Schilling@fokus.fraunhofer.de> References: <201002221928.o1MJSI0M733311@jurassic.Eng.Sun.COM> <4B82DCE6.4050201@sun.com> <4b83ef62.V0o1er9m/oI1Qeg3%Joerg.Schilling@fokus.fraunhofer.de> <4b84f109.R33Bi1+1dZppD0OD%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 24 Feb 2010 15:12:45.0991 (UTC) FILETIME=[D1CF8B70:01CAB563] X-Antispam: No, score=0.0/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 937 "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 signals beyond the name itself. Do some research before > you send the next mail in this ARC case. As you repeatedly do nmot answer my question _why_ you believe that you need more RT signals, it seeems that you did not do any research on whether you really need them. Please first prove that you need the signals...... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Feb 24 07:14:53 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OFEqpb020484 for ; Wed, 24 Feb 2010 07:14:52 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1OFEqhd006469 for ; Wed, 24 Feb 2010 07:14:52 -0800 (PST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1OFEpeY021030 for ; Wed, 24 Feb 2010 15:14:51 GMT Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-1073124 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:14:51 Z Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-19551889 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:14:49 Z Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-37802673 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:14:49 Z Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 0742C6F06E3; Wed, 24 Feb 2010 16:14:47 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 98F0F6F05D9; Wed, 24 Feb 2010 16:14:45 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o1OFEjwp025598; Wed, 24 Feb 2010 16:14:45 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 16:14:45 +0100 Date: Wed, 24 Feb 2010 16:14:45 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: raf@jurassic.sfbay.sun.com, iszczesniak@gmail.com Cc: Scott.Michael@sun.com, psarc-ext@sac.sfbay.sun.com, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com, krister.johansen@sun.com, jordan.vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, gdamore@sun.com, bart.smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b854265.ZKAKNuEf63yqet7t%Joerg.Schilling@fokus.fraunhofer.de> References: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 24 Feb 2010 15:14:45.0585 (UTC) FILETIME=[19182410:01CAB564] X-Antispam: No, score=0.0/5.0, scanned in 1.472sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 794 "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 signals are used as extended USR signals with special > delivery gurantees. SIGUSR1 and SIGUSR2 have been introduced by AT&T (IIRC with SVr2) which is long before POSIX exists. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From carlsonj@workingcode.com Wed Feb 24 07:30:37 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OFUb3i020662 for ; Wed, 24 Feb 2010 07:30:37 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1OFUbdp014318 for ; Wed, 24 Feb 2010 07:30:37 -0800 (PST) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1OFTU8w011560 for ; Wed, 24 Feb 2010 15:30:32 GMT Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay42i.sun.com with ESMTP id BT-MMP-937183 for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:29:53 Z Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-10386437; Wed, 24 Feb 2010 15:29:53 Z Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-24721752; Wed, 24 Feb 2010 15:29:53 Z Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o1OFTiaU024130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 10:29:45 -0500 (EST) Message-ID: <4B8545E8.3050103@workingcode.com> Date: Wed, 24 Feb 2010 10:29:44 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) To: "I. Szczesniak" CC: "Roger A. Faulkner" , krister.johansen@sun.com, gdamore@sun.com, Scott.Michael@sun.com, bart.smaalders@sun.com, jordan.vaughan@sun.com, psarc-ext@sac.sfbay.sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] References: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> In-Reply-To: X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.176sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 832 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 threads as CPUs, what will you do when you first encounter a 1024 CPU machine? How does this solution scale at all with time? I agree that matching Linux is potentially a worthwhile target just for the "me too" and "don't worry so much about porting" aspects, but I don't think the "my application needs a signal per thread" argument holds a great deal of water. It just sounds like the application has unresolved design issues. -- James Carlson 42.703N 71.076W From Darren.Moffat@Sun.COM Wed Feb 24 07:37:32 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OFbWc1020791 for ; Wed, 24 Feb 2010 07:37:32 -0800 (PST) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1OFbVQb018375 for ; Wed, 24 Feb 2010 07:37:32 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1OFbQWX012356 for ; Wed, 24 Feb 2010 15:37:26 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYC00H00Q8B4900@fe-emea-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 24 Feb 2010 15:37:15 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYC006KPRE0HI90@fe-emea-09.sun.com>; Wed, 24 Feb 2010 15:37:13 +0000 (GMT) Date: Wed, 24 Feb 2010 15:37:12 +0000 From: Darren J Moffat Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: <4B8545E8.3050103@workingcode.com> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: "I. Szczesniak" , "Roger A. Faulkner" , Krister.Johansen@Sun.COM, gdamore@Sun.COM, Scott.Michael@Sun.COM, Bart.Smaalders@Sun.COM, Jordan.Vaughan@Sun.COM, psarc-ext@sac.sfbay.sun.com Message-id: <4B8547A8.6040805@Sun.COM> References: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> <4B8545E8.3050103@workingcode.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 646 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 you need one per thread, and you may have as many threads as CPUs, > what will you do when you first encounter a 1024 CPU machine? Or for that mater a currently shipping machine with 128 or 256 CPUs in it since that is already more than the total size of sigset_t never mind the available space. -- Darren J Moffat From Nicolas.Williams@sun.com Wed Feb 24 10:27:33 2010 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OIRXkq026536 for ; Wed, 24 Feb 2010 10:27:33 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o1OHRXkh008984; Wed, 24 Feb 2010 11:27:33 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o1OHRWhQ008983; Wed, 24 Feb 2010 11:27:32 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 24 Feb 2010 11:27:31 -0600 From: Nicolas Williams To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <20100224172731.GK1061@Sun.COM> References: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002240709.o1O79LSB353076@jurassic.Eng.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1822 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 -- From raf@jurassic.sfbay.sun.com Wed Feb 24 14:11:09 2010 Received: from jurassic.Eng.Sun.COM (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1OMB9qS002057 for ; Wed, 24 Feb 2010 14:11:09 -0800 (PST) Received: from rafblade (punchin-raf.SFBay.Sun.COM [10.7.251.247]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with SMTP id o1OMB68X495020; Wed, 24 Feb 2010 14:11:06 -0800 (PST) Message-Id: <201002242211.o1OMB68X495020@jurassic.Eng.Sun.COM> Date: Wed, 24 Feb 2010 17:11:07 -0500 (EST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] To: Nicolas.Williams@sun.com Cc: psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Unv6HjuSoRAOixPmk+twOg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 sun4u sparc Status: RO Content-Length: 2612 > 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 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. 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: #if defined(__EXTENSIONS__) || !defined(_XPG4_2) /* * use of these symbols by applications is injurious * to binary compatibility */ #define NSIG 49 /* valid signals range from 1 to NSIG-1 */ #define MAXSIG 48 /* size of u_signal[], NSIG-1 <= MAXSIG */ #endif /* defined(__EXTENSIONS__) || !defined(_XPG4_2) */ The offending applications would fail to compile after NSIG and MAXSIG became run-time calls to _sysconf(). Static arrays using these values would have to become dynamically allocated arrays. Such arrays embedded in other statically-allocated structures would be an even worse headache. It would be a major programming job to fix the offending applications. > > 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. I suppose that astonishment/surprise is in the eye of the beholder. *I* would be astonished. Roger From Nicolas.Williams@sun.com Wed Feb 24 15:50:24 2010 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1ONoOLv003324 for ; Wed, 24 Feb 2010 15:50:24 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o1OMoOn4009222; Wed, 24 Feb 2010 16:50:24 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o1OMoNjO009221; Wed, 24 Feb 2010 16:50:23 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 24 Feb 2010 16:50:23 -0600 From: Nicolas Williams To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <20100224225023.GV1061@Sun.COM> References: <201002242211.o1OMB68X495020@jurassic.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002242211.o1OMB68X495020@jurassic.Eng.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1800 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 using these values would have to become dynamically > allocated arrays. Such arrays embedded in other statically-allocated > structures would be an even worse headache. It would be a major > programming job to fix the offending applications. I can see other ways in which apps might fail. But I don't see how that relates to having a tunable number of rt signals vs. a static one -- the problems arise just from changing the number of RT signals. Consider an app that has a statically allocated array of things relating to signals, using MAXSIG as the array size. And imagine that that application uses SIGRTMAX (which is not constant) as an index into that array. If built on S10 and run on OpenSolaris that application may fail at runtime, hopefully safely (because it checks array bounds). The problem is that SIGRTMAX (and even SIGRTMIN, technically) can, at runtime, be larger than MAXSIG was at compile-time. I think NSIG/MAXSIG need to be macros that expand into sysconf() calls, just like SIGRT*. > > If so then the principle of least surprise does not apply as you > > suggest. > > I suppose that astonishment/surprise is in the eye of the beholder. Yes. > *I* would be astonished. But won't programs built earlier have such problems as you described anyways just from our increasing NSIG/MAXSIG and SIGRTMIN/MAX? That's what I think makes the priniciple of least surprise inapplicable: just by increasing the number of signals we could be breaking people anyways. Nico -- From raf@jurassic.sfbay.sun.com Mon Mar 1 08:37:19 2010 Received: from jurassic.Eng.Sun.COM (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o21GbJCL025138 for ; Mon, 1 Mar 2010 08:37:19 -0800 (PST) Received: from rafblade (punchin-raf.SFBay.Sun.COM [10.7.251.247]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with SMTP id o21GbGvV336071; Mon, 1 Mar 2010 08:37:17 -0800 (PST) Message-Id: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> Date: Mon, 1 Mar 2010 11:37:16 -0500 (EST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] To: psarc-ext@sac.sfbay.sun.com Cc: Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: h36SRoI9aj10SBdF81IMRg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 sun4u sparc Status: RO Content-Length: 2434 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. It would not relieve any pressure on kernel data structures. Those would have to be configured for the maximum tunable value. It would not enable a possible future reduction in the maximum tunable value because some customers will use the maximum value and we would do them a disservice (and incur their wrath) by reducing it. Therefore, the value of {RTSIG_MAX} will be a fixed quantity (as will NSIG and MAXSIG). 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. This fast-track times out at close-of-business today. Roger Fauilkner From Darren.Moffat@Sun.COM Mon Mar 1 10:32:44 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o21IWhXo027875 for ; Mon, 1 Mar 2010 10:32:43 -0800 (PST) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o21IWewC022240 for ; Mon, 1 Mar 2010 10:32:40 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o21IWYfN016590 for ; Mon, 1 Mar 2010 18:32:34 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYM0000088D6900@fe-emea-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 01 Mar 2010 18:32:19 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYM00BER8TU0OC0@fe-emea-10.sun.com>; Mon, 01 Mar 2010 18:32:19 +0000 (GMT) Date: Mon, 01 Mar 2010 18:32:18 +0000 From: Darren J Moffat Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> Sender: Darren.Moffat@Sun.COM To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Scott.Michael@Sun.COM, Krister.Johansen@Sun.COM, Bart.Smaalders@Sun.COM, Jordan.Vaughan@Sun.COM, gdamore@Sun.COM, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com, Nicolas.Williams@Sun.COM Message-id: <4B8C0832.8040404@Sun.COM> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1958 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. -- Darren J Moffat From gdamore@sun.com Mon Mar 1 13:15:13 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o21LFDMK002852 for ; Mon, 1 Mar 2010 13:15:13 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o21LFDUD028140 for ; Mon, 1 Mar 2010 13:15:13 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o21LF818012172 for ; Mon, 1 Mar 2010 13:15:08 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYM00300GCMCQ00@fe-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 01 Mar 2010 13:15:08 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYM00HAHGD79K90@fe-sfbay-10.sun.com>; Mon, 01 Mar 2010 13:15:07 -0800 (PST) Date: Mon, 01 Mar 2010 13:15:07 -0800 From: "Garrett D'Amore" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com Message-id: <4B8C2E5B.1090903@sun.com> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 2690 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. Although the idea of making {RTSIG_MAX} be a system tunable > is an intriguing possibility, it would have marginal utility. > > It would not relieve any pressure on kernel data structures. > Those would have to be configured for the maximum tunable value. > > It would not enable a possible future reduction in the maximum > tunable value because some customers will use the maximum > value and we would do them a disservice (and incur their wrath) > by reducing it. > > Therefore, the value of {RTSIG_MAX} will be a fixed quantity > (as will NSIG and MAXSIG). > > 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. > > This fast-track times out at close-of-business today. > > Roger Fauilkner > > From iszczesniak@gmail.com Mon Mar 1 20:55:11 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o224tBaM012159 for ; Mon, 1 Mar 2010 20:55:11 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o224tBGl007041 for ; Mon, 1 Mar 2010 20:55:11 -0800 (PST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o224t5a1006831 for ; Tue, 2 Mar 2010 04:55:05 GMT Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-1447420 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 04:53:05 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-32918372 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 04:53:05 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-617416 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 04:53:04 Z Received: by bwz26 with SMTP id 26so2616964bwz.27 for ; Mon, 01 Mar 2010 20:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+U8CIlal+GjGC+glrwph8nPxH82tJR3Wsheb0kE02v0=; b=HF5x1bPb003UFbOvY1eiK8rB8Grwhpb3s3qujMk9RjFJLcTVV1pFEI/GvyJKyoffTF PgOQBOeD5zFKI9YUjvM6btYLDXAP1CfzQGEBamCipVOpcTYeuMV2jjH9xP2Npw4j77tP WXpPYCW+kpAW2qkx7pR+Ne91bLFmrngsuybLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KyNLcablT+SivqDL7LHSLZjwxOxxQo/Dw8N5ZEKHhIJoKCGSDtSVZejQrXP+l2zDfu 7Zxyyre9EsfpnlcJjaME80orvW5w7mKeHAZ+7hsEBZ3K39XvZbI0FZGYb8DxyqEOyZ7p ZVqS0QraD3ZFPdvLdyviOIjJjlyba/wgC+ccA= Received: by 10.204.32.198 with SMTP id e6mr3825610bkd.169.1267505576095; Mon, 01 Mar 2010 20:52:56 -0800 (PST) In-Reply-To: <4B8C0832.8040404@Sun.COM> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C0832.8040404@Sun.COM> Date: Tue, 2 Mar 2010 05:52:55 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: Darren J Moffat Cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, gdamore@sun.com, john.plocher@gmail.com, jason@ansipunx.net, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.2/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 2213 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' 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 From iszczesniak@gmail.com Mon Mar 1 20:56:19 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o224uJZL012258 for ; Mon, 1 Mar 2010 20:56:19 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o224uJPr009411 for ; Mon, 1 Mar 2010 20:56:19 -0800 (PST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o224mjIk006029 for ; Tue, 2 Mar 2010 04:56:13 GMT Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-1447508 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 04:56:13 Z Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-30950468 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 04:56:13 Z Received: from mail-bw0-f226.google.com ([209.85.218.226] [209.85.218.226]) by relay1i.sun.com with ESMTP id BT-MMP-2119625 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 04:56:13 Z Received: by bwz26 with SMTP id 26so2618013bwz.27 for ; Mon, 01 Mar 2010 20:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SI0PRROTFFi4sUxT/dFK/4PPivdFbZndzADiUZG8Clk=; b=pasZpO2+EXYaqZzBQOYBO1xQflws56IhEuLE8AabZimmmK/xND7FRoNnhxAnPGLDoV L1MT3POgSpW7jFDbv9ZBmepBISgQRPOKaEqtmpMAMYsVy5S9qc+FhqliQM/rTnNVBcu5 +8L4MU3cbgbtrT95HNkz8EAeyYpKBLrQgY2Fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LrtXJMPiBM/Zd6yGotDP1F7200KLfYmqXtIzQ45MTNyu9vmacRr84pTx+i3DeEQlJT 2W9JSWRlgcZQ4AyZdgYKjMY61MgQKrP49oz1m/4hwDtYHnW8JmzmXSPIBiqLiW+pT1Co QN3tMkE1ai47yMff3yYJ9Eq0VU8EjwyWq0HkY= Received: by 10.204.34.208 with SMTP id m16mr3854825bkd.180.1267505771854; Mon, 01 Mar 2010 20:56:11 -0800 (PST) In-Reply-To: <4B8C2E5B.1090903@sun.com> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C2E5B.1090903@sun.com> Date: Tue, 2 Mar 2010 05:56:11 +0100 Message-ID: Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] From: "I. Szczesniak" To: "Garrett D'Amore" Cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.049sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Status: RO Content-Length: 276 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 From gdamore@sun.com Mon Mar 1 21:05:03 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o225528L012379 for ; Mon, 1 Mar 2010 21:05:02 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o22552vd029593 for ; Mon, 1 Mar 2010 21:05:02 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2254vt6008466 for ; Mon, 1 Mar 2010 21:04:57 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYN00H001ZLW800@fe-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 01 Mar 2010 21:04:57 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYN00C6Z24654J0@fe-sfbay-10.sun.com>; Mon, 01 Mar 2010 21:04:56 -0800 (PST) Date: Mon, 01 Mar 2010 21:04:54 -0800 From: "Garrett D'Amore" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: Sender: Garrett.Damore@sun.com To: "I. Szczesniak" Cc: Darren J Moffat , "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com Message-id: <4B8C9C76.80207@sun.com> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C0832.8040404@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 2097 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 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 From gdamore@sun.com Mon Mar 1 21:06:46 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2256k83012393 for ; Mon, 1 Mar 2010 21:06:46 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2256hKw005789 for ; Mon, 1 Mar 2010 21:06:43 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2256cbC008545 for ; Mon, 1 Mar 2010 21:06:38 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYN0020024BX600@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Mon, 01 Mar 2010 21:06:38 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYN00LZG271Q0H0@fe-sfbay-09.sun.com>; Mon, 01 Mar 2010 21:06:38 -0800 (PST) Date: Mon, 01 Mar 2010 21:06:37 -0800 From: "Garrett D'Amore" Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-reply-to: Sender: Garrett.Damore@sun.com To: "I. Szczesniak" Cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Scott.Michael@sun.com, Krister.Johansen@sun.com, Bart.Smaalders@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, Joerg.Schilling@fokus.fraunhofer.de, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com Message-id: <4B8C9CDD.8000503@sun.com> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C2E5B.1090903@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 529 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 realtime signals) do? > > Irek > Change their code to use sigqueue() and not depend on a non-portable operating system specific configuration such as the number of real-time signals present. - Garrett From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Mar 2 02:18:37 2010 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o22AIb4H003574 for ; Tue, 2 Mar 2010 02:18:37 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o22AIagR025030 for ; Tue, 2 Mar 2010 02:18:36 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o22AIZqk026060 for ; Tue, 2 Mar 2010 10:18:35 GMT Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-1330252 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 10:18:35 Z Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-22074784 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 10:18:34 Z Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-1638730 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 10:18:33 Z Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 4C7F663C186; Tue, 2 Mar 2010 11:18:32 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 9A88663C09F; Tue, 2 Mar 2010 11:18:29 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o22AITiv004931; Tue, 2 Mar 2010 11:18:29 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 11:18:29 +0100 Date: Tue, 02 Mar 2010 11:18:29 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: iszczesniak@gmail.com, Darren.Moffat@sun.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, gdamore@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b8ce5f5.e7Q5O/8CbY/XXXny%Joerg.Schilling@fokus.fraunhofer.de> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C0832.8040404@Sun.COM> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 02 Mar 2010 10:18:29.0116 (UTC) FILETIME=[B3F8BBC0:01CAB9F1] X-Antispam: No, score=0.0/5.0, scanned in 0.606sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 848 "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 > Linux defaults and not those from BSD or AIX? Without such a case this > argument is invalid. Well, did you recently implement a BSD and AIX branded zone? The only reason for supporting the numbers from Linux seems to be brandz. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Mar 2 02:20:09 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o22AK9Xd003610 for ; Tue, 2 Mar 2010 02:20:09 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o22AK8sR028215 for ; Tue, 2 Mar 2010 02:20:08 -0800 (PST) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o22AK8i6022633 for ; Tue, 2 Mar 2010 10:20:08 GMT Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay42i.sun.com with ESMTP id BT-MMP-1350939 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 10:20:08 Z Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-22076397 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 10:20:07 Z Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay4i.sun.com with ESMTP id BT-MMP-35384894 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 10:20:07 Z Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 11EB06F069B; Tue, 2 Mar 2010 11:20:06 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 195BA6F065D; Tue, 2 Mar 2010 11:20:04 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o22AK4Sa004984; Tue, 2 Mar 2010 11:20:04 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 11:20:04 +0100 Date: Tue, 02 Mar 2010 11:20:04 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: iszczesniak@gmail.com, gdamore@sun.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b8ce654.ecMaMyFqbr0bX07B%Joerg.Schilling@fokus.fraunhofer.de> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C2E5B.1090903@sun.com> In-Reply-To: User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 02 Mar 2010 10:20:04.0366 (UTC) FILETIME=[ECBEBAE0:01CAB9F1] X-Antispam: No, score=0.0/5.0, scanned in 0.066sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 793 "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 encourage you to explain us _why_ you believe that more than 32 real time signals are needed....... Just demanding a higher number does nmot look constructive. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From casper@holland.sun.com Tue Mar 2 02:28:23 2010 Received: from dm-holland-01.uk.sun.com (dm-holland-01.UK.Sun.COM [129.156.101.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o22ASMte003707 for ; Tue, 2 Mar 2010 02:28:23 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-01.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o22ASEjv000573; Tue, 2 Mar 2010 10:28:14 GMT Message-Id: <201003021028.o22ASEjv000573@dm-holland-01.uk.sun.com> From: Casper.Dik@sun.com To: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) cc: iszczesniak@gmail.com, Darren.Moffat@sun.com, Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, gdamore@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] In-Reply-To: <4b8ce5f5.e7Q5O/8CbY/XXXny%Joerg.Schilling@fokus.fraunhofer.de> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C0832.8040404@Sun.COM> <4b8ce5f5.e7Q5O/8CbY/XXXny%Joerg.Schilling@fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 02 Mar 2010 11:28:14 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 626 >"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 >> Linux defaults and not those from BSD or AIX? Without such a case this >> argument is invalid. > >Well, did you recently implement a BSD and AIX branded zone? > >The only reason for supporting the numbers from Linux seems to be brandz. I think it's also needed to support source code. Casper From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Mar 2 03:02:25 2010 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o22B2Pn4004225 for ; Tue, 2 Mar 2010 03:02:25 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o22B2OGT013321 for ; Tue, 2 Mar 2010 03:02:24 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o22B1Hx4002257 for ; Tue, 2 Mar 2010 11:02:24 GMT Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-564486 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 11:02:24 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-182915 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 11:02:23 Z Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay1i.sun.com with ESMTP id BT-MMP-1210362 for psarc-ext@sac.sfbay.sun.com; Tue, 2 Mar 2010 11:02:23 Z Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 80F5463C1C6; Tue, 2 Mar 2010 12:02:21 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 95C8763C1B4; Tue, 2 Mar 2010 12:02:06 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o22B268Y006142; Tue, 2 Mar 2010 12:02:06 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 12:02:05 +0100 Date: Tue, 02 Mar 2010 12:02:06 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: Casper.Dik@sun.com Cc: Scott.Michael@sun.com, raf@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, olga.kryzhanovska@gmail.com, Nicolas.Williams@sun.com, Krister.Johansen@sun.com, Jordan.Vaughan@sun.com, john.plocher@gmail.com, jason@ansipunx.net, iszczesniak@gmail.com, gdamore@sun.com, Darren.Moffat@sun.com, Bart.Smaalders@sun.com Subject: Re: increase number of realtime signals [PSARC/2010/062 Self Review] Message-ID: <4b8cf02e.9Ph/hHoVjqYjx4mK%Joerg.Schilling@fokus.fraunhofer.de> References: <201003011637.o21GbGvV336071@jurassic.Eng.Sun.COM> <4B8C0832.8040404@Sun.COM> <4b8ce5f5.e7Q5O/8CbY/XXXny%Joerg.Schilling@fokus.fraunhofer.de> <201003021028.o22ASEjv000573@dm-holland-01.uk.sun.com> In-Reply-To: <201003021028.o22ASEjv000573@dm-holland-01.uk.sun.com> User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 02 Mar 2010 11:02:05.0834 (UTC) FILETIME=[CBA836A0:01CAB9F7] X-Antispam: No, score=-0.2/5.0, scanned in 0.669sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 1169 Casper.Dik@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 are programs that use higher numbers. Solaris is already POSIX conpliant and I believe that _we_ the OpenSolaris community also need to educate software authors how to correctly follow POSIX constraints instead of writing code that depends on platform specific features or parameters. This is not only a problem with the number of RT signals but a general problem with software that has been developed on e.g. Linux. Writing portable code first means to understand what features are platform specific and how to do the same thing by only relying on standard features. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily