CSR for posix_spawn on JDK 12
david.holmes at oracle.com
Wed Dec 5 10:44:17 UTC 2018
Pardon the top-posting but ...
The launchMechanism property was introduced by the following issue:
at the time there was no CSR process and it went through our internal
CCC process. The "specification" was as follows:
jdk.lang.Process.launchMechanism is read once on initialisation. If an
invalid value is provided an Error will be thrown immediately stating
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".
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
> 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
> (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
More information about the core-libs-dev