RFR 9: 7021006: (process) Remove disabled clone-exec feature

Roger Riggs Roger.Riggs at Oracle.com
Fri Mar 27 21:54:20 UTC 2015


ok,  restored.

I'd hope this isn't the only place that lore exists but it's 
conveniently located.

Thanks, Roger


On 3/27/2015 5:47 PM, Martin Buchholz wrote:
>
>
> On Fri, Mar 27, 2015 at 2:28 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Martin,
>
>     That part seems both dated and arcane;  it will be in the
>     mercurial history
>     none the less.  I can't see how it could be applied unless we go
>     back to clone.
>
>
> This is information for implementers of subprocess creation, that I 
> still consider useful, and I personally refer to every couple of 
> years.  I would be unhappy to see it go.
>
>     Roger
>
>
>
>     On 3/27/2015 5:21 PM, Martin Buchholz wrote:
>>     Please also keep (most of?) the below.  The key piece of the
>>     history is that glibc did not consider clone a public supported
>>     interface, unlike vfork, but that might change. This comment and
>>     the contents of the glibc bug are an important part of Unix lore,
>>     although I'm hearing you think there's a better place to record
>>     the arcane history of Unix...
>>
>>     - * - clone() with flags CLONE_VM but not CLONE_THREAD.  clone() is
>>     - *   Linux-specific, but this ought to work - at least the glibc
>>     - *   sources contain code to handle different combinations of CLONE_VM
>>     - *   and CLONE_THREAD.  However, when this was implemented, it
>>     - *   appeared to fail on 32-bit i386 (but not 64-bit x86_64) Linux with
>>     - *   the simple program
>>     - *     Runtime.getRuntime().exec("/bin/true").waitFor();
>>     - *   with:
>>     - *     #  Internal Error (os_linux_x86.cpp:683), pid=19940, tid=2934639536
>>     - *     #  Error: pthread_getattr_np failed with errno = 3 (ESRCH)
>>     - *   We believe this is a glibc bug, reported here:
>>     - *http://sources.redhat.com/bugzilla/show_bug.cgi?id=10311
>>     - *   but the glibc maintainers closed it as WONTFIX.
>>     - *
>>
>>
>>     On Fri, Mar 27, 2015 at 2:14 PM, Roger Riggs
>>     <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>>         Thanks Martin,
>>
>>         Updated the webrev in place to restore that context.
>>
>>         Roger
>>
>>
>>
>>         On 3/27/2015 5:00 PM, Martin Buchholz wrote:
>>>         clone was never used in a released jdk.
>>>
>>>         I would leave the internal docs.  I left them in on purpose,
>>>         because it was not at all obvious why we chose not to use clone.
>>>
>>>         I'm especially fond of
>>>         - *   On Linux, one might think that vfork() would be implemented using
>>>         - *   the clone system call with flag CLONE_VFORK, but in fact vfork is
>>>         - *   a separate system call (which is a good sign, suggesting that
>>>         - *   vfork will continue to be supported at least on Linux).
>>>         Deleting the implementation using clone is a better idea;
>>>         it's easy to resurrect in the unlikely case someone will
>>>         want to.
>>>
>>>
>>>         On Fri, Mar 27, 2015 at 1:50 PM, Roger Riggs
>>>         <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>>
>>>             At one time clone() was used on Unix to spawn processes
>>>             but no more.
>>>             Please review the cleanup of now dead code.
>>>
>>>             Webrev:
>>>             http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
>>>             <http://cr.openjdk.java.net/%7Erriggs//webrev-clone-7021006>
>>>
>>>             Issue:
>>>             https://bugs.openjdk.java.net/browse/JDK-7021006
>>>
>>>             Thanks, Roger
>>>
>>>
>>
>>
>
>




More information about the core-libs-dev mailing list