CSR for posix_spawn on JDK 12

[Thomas Stüfe]

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
>
>
>