>Date: Wed, 01 Oct 2008 05:28:10 -0700 (PDT)
>From: "Roger A. Faulkner" <Roger.Faulkner at sun.com>
>
>> Date: Tue, 30 Sep 2008 21:04:52 -0700
>> From: "Garrett D'Amore" <gdamore at 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,
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 <spawn.h>. (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
<mqueue.h> for implementation use and names starting with pthread_ and
PTHREAD_ in <pthread.h> 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
