Review request for 5049299

[Martin Buchholz]

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:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090701/3ab1275d/attachment-0001.html>