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.mcma...@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: > posix_spawn() 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. >
