Review request for 5049299 (original) (raw)

Martin Buchholz martinrb at google.com
Wed Jul 1 14:56:52 UTC 2009

Sorry this is taking so long to get in. The current situation is that I have two changes out for review. http://cr.openjdk.java.net/~martin/vfork-exec/ http://cr.openjdk.java.net/~martin/RESTARTABLE/ That appear to work on Linux. Michael, please file bugs in bugtraq and review. Then we put in your processhelper code. We have some issues about how best to organize the processhelper code that we still need to resolve.

(The recent email involving glibc are not directly relevant since we won't be able to benefit from any glibc changes nearterm)

I've been thinking we should go further than having compile-time support for choosing the fork-method and add a system property to select among the 4 different ways of starting a subprocess. The kinds of changes being made will still be risky and it would be nice to have a way to revert to the safer fork() strategy.

Martin

On Wed, Jul 1, 2009 at 05:55, Michael McMahon <Michael.McMahon at sun.com>wrote:

Can we decide on a plan for this issue? I'd like to have it resolved in good time for M5.

Architecturally, the solution for Solaris is clear I think: posixspawn() of helper program which exec()'s the final target. So, can we recap on what the situation is for Linux? Is it vfork() plus exec()? But ,if (as the man page suggests) vfork() is just a special case of clone(), then are we sure there still isn't too much "stuff happening" between clone()/vfork() and exec() ? Maybe, if this question isn't resolved (or resolvable) soon then should we go ahead with a Solaris only fix? - Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090701/3ab1275d/attachment-0001.html>

More information about the core-libs-dev mailing list