CSR for posix_spawn on JDK 12

[David Holmes]

Hi Thomas,

Pardon the top-posting but ...

The launchMechanism property was introduced by the following issue:

https://bugs.openjdk.java.net/browse/JDK-5049299

at the time there was no CSR process and it went through our internal 
CCC process. The "specification" was as follows:

---
Specification
jdk.lang.Process.launchMechanism is read once on initialisation. If an 
invalid value is provided an Error will be thrown immediately stating 
the reason.

On Linux: jdk.lang.Process.launchMechanism can be set to fork or vfork - 
defaults to vfork on JDK7 & 8
On Solaris: jdk.lang.Process.launchMechanism can be set to posix_spawn 
or fork - defaults to fork on JDK7 and posix_spawn on JDK8
On Mac OS X: jdk.lang.Process.launchMechanism can be set to posix_spawn 
or fork - defaults to posix_spawn on JDK7 & 8
---

so IMHO for this issue the "specification" should simply be:

Update the allowed values of the jdk.lang.Process.launchMechanism 
property on Linux to accept the value "posix_spawn", which will use the 
posix_spawn() API. The default value of "vfork" remains unchanged.

---

But as the CSR has already been approved I'm not sure why we are 
"rearranging the deck chairs".

Cheers,
David
-----



On 5/12/2018 6:05 pm, Thomas Stüfe wrote:
> Hi Roger,
> 
> thanks for all your help, I appreciate it.
> 
> I thought a while and got some fundamental doubts about the whole
> process, see inline.
> 
> On Fri, Nov 30, 2018 at 9:21 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>> Hi Thomas,
>>
>> On 11/30/2018 02:06 PM, Thomas Stüfe wrote:
>>
>> Hi Roger,
>>
>> I updated the CSR according to your feedback. I'm a bit at a loss
>> about the specification though. How should I specify the behavior of
>> the API without describing the implementation?
>>
>> What you wrote is fine. It does need to mention posix_spawn by name,
>> as that is the OS function being used.
>>
>> The notes about the behavior of libc, fit better as an explanation
>> in the description of the Solution than in the Specification section.
>>
>>
>> Also, since this patch only extends an existing implementation to
>> Linux, I would have thought there are there technical notes in place
>> describing POSIX_SPAWN on other platforms, which I would have just
>> refered to. I searched but could not really find anything.
>>
>> Nope, that's why it was a debugging tool for Martin,
>> not a documented implementation feature.
> 
> See, here I start getting confused. Has this switch ever been an
> officially released feature?
> 
> If yes, I should be able to find release notes, documentation etc I
> could refer to and/or copy from.
> If not, why should we file a CSR and a release note for adding an
> accepted value to a feature which has never been officially released?
> 
> This explains also my problems in formulating the CSR/release note.
> How can I describe something without describing its implementation, if
> the something is just basically implementation and no feature. It has
> no discernible API the user would face, and the consequences for
> switching the feature are difficult to describe in 1-2 sentences
> without delving deeply into details. 1-2 sentences also run the risk
> of giving a false picture.
> 
> Basically, I do not see a difference between this switch and any other
> diagnostic hotspot switch, e.g., and therefore am undecided on what to
> do here.
> 
> (Should I redirect these questions to the original mail thread?)
> 
>>
>> I'm not sure what the proper plural of Unix's is but Unices looks odd.
>> Perhaps avoid the issue and just say Unix platforms.
>>
> 
> Unices is fine I think. See:  https://en.wikipedia.org/wiki/Unix
> 
> <quote>
> Most common is the conventional Unixes, but _Unices_, treating Unix as
> a Latin noun of the third declension, is also popular. The
> pseudo-Anglo-Saxon plural form Unixen is not common, although
> occasionally seen. Sun Microsystems, developer of the Solaris variant,
> has asserted that the term Unix is itself plural, referencing its many
> implementations.[42]
> </quote>
> 
> (Unixen sounds weird and genglish though :)
> 
> Thanks, Thomas
> 
>>
>> On Fri, Nov 30, 2018 at 3:50 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>> Hi Thomas,
>>
>> Looks pretty good.
>>
>> Usually 'we' avoid the first person writing in the jira.
>> It makes them more readable in the long term, when there is no context for 'we'.
>>
>> - Describing it as 'experimental' gives the wrong impression
>> and has some magnified implications as that term is being used for
>> other major changes.
>>
>> - The compatibility risk should be corrected:
>>
>> Supplying an unknown value on the command line produces a java.lang.Error.
>>
>> % java -Djdk.lang.Process.launchMechanism=POSIX_SPAWN ...
>>
>> java.lang.Error: POSIX_SPAWN is not a supported process launch mechanism on this platform.
>>
>> - Since CSRs should be self contained, the specification section should explicitly
>> specify the behavior from the API point of view. CSRs should avoid describing
>> the implementation (though in this case, its not entirely possible).
>> The webrev of the impl is not relevant.
>>
>> Thanks, Roger
>>
>>
>> On 11/30/2018 03:32 AM, Thomas Stüfe wrote:
>>
>> CSR for jdk12: https://bugs.openjdk.java.net/browse/JDK-8214511
>>
>> ..Thomas
>>
>>
>>