From sacadmin Tue Sep 30 15:16:49 2008 Received: from sunraf.sfbay.sun.com (sunraf.SFBay.Sun.COM [129.146.177.11]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8UMGnmX002901; Tue, 30 Sep 2008 15:16:49 -0700 (PDT) Received: from sunraf.sfbay.sun.com (localhost [127.0.0.1]) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8UMGlAr133090; Tue, 30 Sep 2008 15:16:48 -0700 (PDT) Received: (from raf@localhost) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m8UMGlJ0133086; Tue, 30 Sep 2008 15:16:47 -0700 (PDT) Date: Tue, 30 Sep 2008 15:16:47 -0700 (PDT) From: "Roger A. Faulkner" Message-Id: <200809302216.m8UMGlJ0133086@sunraf.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: posix_spawn(3C) extension - setsigignore [PSARC/2008/617 Self Review] Status: RO Content-Length: 578 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: posix_spawn(3C) extension - setsigignore 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 30 September, 2008 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: OS/NET 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Roger.Faulkner@sun.com Tue Sep 30 19:58:20 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m912wKbS009289 for ; Tue, 30 Sep 2008 19:58:20 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id m912vWQG850619; Tue, 30 Sep 2008 19:57:38 -0700 (PDT) Message-Id: <200810010257.m912vWQG850619@jurassic-x4600.sfbay.sun.com> Date: Tue, 30 Sep 2008 19:57:32 -0700 (PDT) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: PSARC/2008/617 - posix_spawn extension - setsigignore To: psarc-ext@sac.sfbay.sun.com Cc: sumanth.naropanth@sun.com, bart.smaalders@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cWWCGidMI0PbhEG0D14cyQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1530 I am sponsoring this automatic-approval case for myself. The proposal in this case is to extend the posix_spawn() functionality by adding the ability to specify a set of signals that are to be ignored in the created child process. The Posix specification for posix_spawn() already provides a way to set the child's signal handlers to SIG_DFL via the POSIX_SPAWN_SETSIGDEF flag to posix_spawnattr_setflags() plus the functions: posix_spawnattr_setsigdefault() posix_spawnattr_getsigdefault() However, it provides no way to set the child's signal actions to SIG_IGN other than having them inherited from the calling process. It is not thread-safe for one thread of a process to change signal actions for this purpose, even if the actions are changed back immediately following the call to posix_spawn(). What is needed is a way to set the child's signal handlers to SIG_IGN via a POSIX_SPAWN_SETSIGIGN_NP flag to posix_spawnattr_setflags() plus new functions: posix_spawnattr_setsigignore_np() posix_spawnattr_getsigignore_np() (The _NP and _np appendages are for non-portable Solaris extensions.) The old and new posix_spawn(3C) manual pages are in the materials directory, along with the new manual page for the new functions: posix_spawnattr_getsigignore_np.3c The proposed commitment level of these new interfaces is Committed. The proposed release binding is "minor release" so they can go into SunOS 5.11 (there is no need or intention to back-port the interfaces to SunOS 5.10). Roger Faulkner From gdamore@sun.com Tue Sep 30 21:07:55 2008 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 m9147tT0010727 for ; Tue, 30 Sep 2008 21:07:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9147swG031272 for ; Tue, 30 Sep 2008 21:07:54 -0700 (PDT) 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 m9147nPr001658 for ; Tue, 30 Sep 2008 21:07:49 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8100001KOOTG00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sac.sfbay.sun.com; Tue, 30 Sep 2008 21:07:49 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8100FLYKSLJCE0@fe-sfbay-09.sun.com>; Tue, 30 Sep 2008 21:07:34 -0700 (PDT) Date: Tue, 30 Sep 2008 21:04:52 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/617 - posix_spawn extension - setsigignore In-reply-to: <200810010257.m912vWQG850619@jurassic-x4600.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Sumanth.Naropanth@sun.com, Bart.Smaalders@sun.com, Darrin.Johnson@sun.com Message-id: <48E2F6E4.1080505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200810010257.m912vWQG850619@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1888 Q: Has there been any activity (that you're aware of) to amend the standard to support this kind of functionality? Is this something that our representative(s) with the POSIX group should be proposing for the next revision of the standard? -- Garrett Roger A. Faulkner wrote: > I am sponsoring this automatic-approval case for myself. > > The proposal in this case is to extend the posix_spawn() > functionality by adding the ability to specify a set of > signals that are to be ignored in the created child process. > > The Posix specification for posix_spawn() already provides a way to set > the child's signal handlers to SIG_DFL via the POSIX_SPAWN_SETSIGDEF > flag to posix_spawnattr_setflags() plus the functions: > posix_spawnattr_setsigdefault() > posix_spawnattr_getsigdefault() > > However, it provides no way to set the child's signal actions to SIG_IGN > other than having them inherited from the calling process. It is not > thread-safe for one thread of a process to change signal actions > for this purpose, even if the actions are changed back immediately > following the call to posix_spawn(). > > What is needed is a way to set the child's signal handlers to SIG_IGN > via a POSIX_SPAWN_SETSIGIGN_NP flag to posix_spawnattr_setflags() plus > new functions: > posix_spawnattr_setsigignore_np() > posix_spawnattr_getsigignore_np() > > (The _NP and _np appendages are for non-portable Solaris extensions.) > > The old and new posix_spawn(3C) manual pages are in the materials > directory, along with the new manual page for the new functions: > posix_spawnattr_getsigignore_np.3c > > The proposed commitment level of these new interfaces is Committed. > > The proposed release binding is "minor release" so they can go > into SunOS 5.11 (there is no need or intention to back-port the > interfaces to SunOS 5.10). > > Roger Faulkner > > From Roger.Faulkner@sun.com Wed Oct 1 05:28:58 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m91CSwnc021565 for ; Wed, 1 Oct 2008 05:28:58 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id m91CSA1Z964911; Wed, 1 Oct 2008 05:28:15 -0700 (PDT) Message-Id: <200810011228.m91CSA1Z964911@jurassic-x4600.sfbay.sun.com> Date: Wed, 1 Oct 2008 05:28:10 -0700 (PDT) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: PSARC/2008/617 - posix_spawn extension - setsigignore To: gdamore@sun.com, don.cragun@sun.com Cc: psarc-ext@sac.sfbay.sun.com, Sumanth.Naropanth@sun.com, Bart.Smaalders@sun.com, Darrin.Johnson@sun.com, lee.damico@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9i8f1w+0gk5MKtF5T6qT2A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2686 > Date: Tue, 30 Sep 2008 21:04:52 -0700 > From: "Garrett D'Amore" > Subject: Re: PSARC/2008/617 - posix_spawn extension - setsigignore > To: "Roger A. Faulkner" > Cc: psarc-ext@sac.sfbay.sun.com, Sumanth.Naropanth@sun.com, Bart.Smaalders@sun.com, Darrin.Johnson@sun.com > > Q: Has there been any activity (that you're aware of) to amend the > standard to support this kind of functionality? Is this something that > our representative(s) with the POSIX group should be proposing for the > next revision of the standard? > > -- Garrett Garrett: There has been no such activity as far as I know. The SUSv4 specification has just been approved and it contains nothing about this in the posix_spawn() specification. Don: (Sorry, I should have Cc'd you on the original PSARC mail, shown below.) Do you know of any such discussions by the Posix folks? Do you think it's something we should propose to Posix for the future? Thanks, Roger > Roger A. Faulkner wrote: > > I am sponsoring this automatic-approval case for myself. > > > > The proposal in this case is to extend the posix_spawn() > > functionality by adding the ability to specify a set of > > signals that are to be ignored in the created child process. > > > > The Posix specification for posix_spawn() already provides a way to set > > the child's signal handlers to SIG_DFL via the POSIX_SPAWN_SETSIGDEF > > flag to posix_spawnattr_setflags() plus the functions: > > posix_spawnattr_setsigdefault() > > posix_spawnattr_getsigdefault() > > > > However, it provides no way to set the child's signal actions to SIG_IGN > > other than having them inherited from the calling process. It is not > > thread-safe for one thread of a process to change signal actions > > for this purpose, even if the actions are changed back immediately > > following the call to posix_spawn(). > > > > What is needed is a way to set the child's signal handlers to SIG_IGN > > via a POSIX_SPAWN_SETSIGIGN_NP flag to posix_spawnattr_setflags() plus > > new functions: > > posix_spawnattr_setsigignore_np() > > posix_spawnattr_getsigignore_np() > > > > (The _NP and _np appendages are for non-portable Solaris extensions.) > > > > The old and new posix_spawn(3C) manual pages are in the materials > > directory, along with the new manual page for the new functions: > > posix_spawnattr_getsigignore_np.3c > > > > The proposed commitment level of these new interfaces is Committed. > > > > The proposed release binding is "minor release" so they can go > > into SunOS 5.11 (there is no need or intention to back-port the > > interfaces to SunOS 5.10). > > > > Roger Faulkner From don.cragun@Sun.COM Wed Oct 1 09:01:36 2008 Received: from spartan.eng.sun.com (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m91G1aS9027359 for ; Wed, 1 Oct 2008 09:01:36 -0700 (PDT) Received: from spartan (spartan [129.146.226.64]) by spartan.eng.sun.com (8.13.7+Sun/8.13.7) with SMTP id m91G1aJQ004827; Wed, 1 Oct 2008 09:01:36 -0700 (PDT) Message-Id: <200810011601.m91G1aJQ004827@spartan.eng.sun.com> Date: Wed, 1 Oct 2008 09:01:36 -0700 (PDT) From: Don Cragun Reply-To: Don Cragun Subject: Re: PSARC/2008/617 - posix_spawn extension - setsigignore To: Roger.Faulkner@Sun.COM Cc: psarc-ext@sac.sfbay.sun.com, Sumanth.Naropanth@Sun.COM, Bart.Smaalders@Sun.COM, Darrin.Johnson@Sun.COM, lee.damico@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4V2egxNYjxQWQrktF5zEuA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6.2 SunOS 5.10 sun4u sparc Status: RO Content-Length: 2389 >Date: Wed, 01 Oct 2008 05:28:10 -0700 (PDT) >From: "Roger A. Faulkner" > >> Date: Tue, 30 Sep 2008 21:04:52 -0700 >> From: "Garrett D'Amore" >> >> Q: Has there been any activity (that you're aware of) to amend the >> standard to support this kind of functionality? Is this something that >> our representative(s) with the POSIX group should be proposing for the >> next revision of the standard? >> >> -- Garrett > >Garrett: >There has been no such activity as far as I know. >The SUSv4 specification has just been approved and it >contains nothing about this in the posix_spawn() specification. > >Don: >(Sorry, I should have Cc'd you on the original PSARC mail, shown below.) >Do you know of any such discussions by the Posix folks? >Do you think it's something we should propose to Posix for the future? > >Thanks, >Roger > Roger, You didn't need to Cc me on the PSARC mail; I'm on the PSARC alias. No one has raised this issue for to the groups responsible for POSIX and SUS maintenance. SUSv4 became an official TOG standard a few months ago; IEEE Std 1003.1-2008 was approved by IEEE last Thursday (with the same text as SUSv4). The final ISO ballot to also adopt the same text as ISO/IEC 9945-1:200x should start two weeks from today. So, the next revision of the standards won't happen until 2013 at the earliest. But, we have another problem. The standards reserve all names with the prefixes posix, POSIX, _posix, and _POSIX for standards use only. Even with _NP or _np at the end, the names POSIX_SPAWN_SETSIGIGN_NP, posix_spawnattr_setsigignore_np(), and posix_spawnattr_getsigignore_np() will have to be hidden in the headers when building in standards conformance mode unless the source defines __EXTENSIONS__ before including . (This is different from things like mq_reltimedreceive_np() and pthread_cond_reltimedwait_np() because the standards reserve names starting with mq_ and MQ_ in for implementation use and names starting with pthread_ and PTHREAD_ in for implementation use.) I'll be happy to help you submit an aardvark report to request inclusion of this feature (without the _NP and _np suffixes) in the next revision of the standard. I don't see any reason at this point why there should be any problem getting this feature into the next revision. Cheers, Don From gdamore@Sun.COM Wed Oct 1 11:17:03 2008 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 m91IH3kR002498 for ; Wed, 1 Oct 2008 11:17:03 -0700 (PDT) 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.2) with ESMTP id m91IH3fY033683 for ; Wed, 1 Oct 2008 11:17:03 -0700 (PDT) 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 m91IGwrD018616 for ; Wed, 1 Oct 2008 11:16:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8200A01N9W6G00@fe-sfbay-10.sun.com> (original mail from gdamore@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 01 Oct 2008 11:16:58 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K820030GO44GP50@fe-sfbay-10.sun.com>; Wed, 01 Oct 2008 11:16:53 -0700 (PDT) Date: Wed, 01 Oct 2008 11:14:08 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/617 - posix_spawn extension - setsigignore In-reply-to: <200810011601.m91G1aJQ004827@spartan.eng.sun.com> Sender: Garrett.Damore@Sun.COM To: Don Cragun Cc: Roger.Faulkner@Sun.COM, psarc-ext@sac.sfbay.sun.com, Sumanth.Naropanth@Sun.COM, Bart.Smaalders@Sun.COM, Darrin.Johnson@Sun.COM, lee.damico@Sun.COM Message-id: <48E3BDF0.7050406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200810011601.m91G1aJQ004827@spartan.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2674 Thanks Don and Roger. So I guess the symbols need to be protected as Don suggests. Otherwise it looks pretty good to me. ;-) - Garrett Don Cragun wrote: >> Date: Wed, 01 Oct 2008 05:28:10 -0700 (PDT) >> From: "Roger A. Faulkner" >> >> >>> Date: Tue, 30 Sep 2008 21:04:52 -0700 >>> From: "Garrett D'Amore" >>> >>> Q: Has there been any activity (that you're aware of) to amend the >>> standard to support this kind of functionality? Is this something that >>> our representative(s) with the POSIX group should be proposing for the >>> next revision of the standard? >>> >>> -- Garrett >>> >> Garrett: >> There has been no such activity as far as I know. >> The SUSv4 specification has just been approved and it >> contains nothing about this in the posix_spawn() specification. >> >> Don: >> (Sorry, I should have Cc'd you on the original PSARC mail, shown below.) >> Do you know of any such discussions by the Posix folks? >> Do you think it's something we should propose to Posix for the future? >> >> Thanks, >> Roger >> >> > > Roger, > You didn't need to Cc me on the PSARC mail; I'm on the PSARC > alias. No one has raised this issue for to the groups responsible for > POSIX and SUS maintenance. SUSv4 became an official TOG standard a few > months ago; IEEE Std 1003.1-2008 was approved by IEEE last Thursday > (with the same text as SUSv4). The final ISO ballot to also adopt the > same text as ISO/IEC 9945-1:200x should start two weeks from today. > So, the next revision of the standards won't happen until 2013 at the > earliest. > But, we have another problem. The standards reserve all names > with the prefixes posix, POSIX, _posix, and _POSIX for standards use > only. Even with _NP or _np at the end, the names > POSIX_SPAWN_SETSIGIGN_NP, posix_spawnattr_setsigignore_np(), and > posix_spawnattr_getsigignore_np() will have to be hidden in the headers > when building in standards conformance mode unless the source defines > __EXTENSIONS__ before including . (This is different from > things like mq_reltimedreceive_np() and pthread_cond_reltimedwait_np() > because the standards reserve names starting with mq_ and MQ_ in > for implementation use and names starting with pthread_ and > PTHREAD_ in for implementation use.) > I'll be happy to help you submit an aardvark report to request > inclusion of this feature (without the _NP and _np suffixes) in the > next revision of the standard. I don't see any reason at this point > why there should be any problem getting this feature into the next > revision. > > Cheers, > Don > >