vfork instead of fork for fork+exec?

[Martin Buchholz]

On Sat, May 16, 2009 at 11:56, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> Christos Zoulas wrote:
>>
>> On BSD vfork() does not share file descriptors, current working
>> directory, and signals, and as the following program shows environment
>> too so all the items are fine (and it is trivial to write code that
>> proves this). If that was not the case (file descriptors were shared
>> for example), vfork() would be useless.  Even the shell does not
>> (because it cannot) use vfork() in every situation, but only when
>> it can. I don't know if it is worth the trouble of using vfork()
>> in java when it is possible, since fork() is not a very common
>> operation in java programs (I think).
>
> The reason it came up for me is that we're trying to make subprocess
> launching not suck in JRuby. For example, there's no way with current
> process APIs on the JVM to launch a program like vim that needs a real
> console to function properly. Using straight-up fork+exec allows that to
> work:
>
> http://blog.headius.com/2009/05/fork-and-exec-on-jvm-jruby-to-rescue.html

Are you aware of
http://download.java.net/jdk7/docs/api/java/lang/ProcessBuilder.html#inheritIO()

In JDK6, you can do something non-portable like

Runtime.exec("/bin/bash", "-c",
"exec /usr/bin/vim < /proc/$PPID/0 > /proc/$PPID/1 2>/proc/$PPID/2")