The rationale of posix_spawn here is a good addition to what we discuss I think : http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html#ta...
And as your goal is Posix + Windows, I understand you don't want to deal with specialities of linux / solaris / ... so I think you're right it's safer the default to be fork.
[snip]
It's with an MMU but the parent process on this product is a memory-hungry-monster-jvm and the fork fails. It seems a bit strange to me, that you would use boost.process here, instead of - you know - java.io.process. But I guess you want performance and your java-developers want a job, so JNI is the way to go?
It's off-topic but to explain: The fact is that they just reuse a C++ library we had for long, where we added a JNI interface for it, which is launching at one point processes that are not developed internally and that we cannot implement as library because we don't have the source code.
Additionally I believe that in the version of jvm implementation used (oracle - arm - early 1.7) I think java.io.process does fork+exec, which has been changed after because of similar issues: http://bugs.java.com/view_bug.do?bug_id=6868160
Thanks for dealing with my wishes to vfork :)
Alright, the feature is in now, you find that in boost/process/posix.hpp - it's not documented though. If you pass posix::use_vfork to the function it will work. BUT: I just removed the test for that, because it ran locally (on my debian VM) but travis didn't like it very much - for some unknown reason. Maybe you have some experience and might be able to find a fix. I'd be really happy to have a test for this - I'd just need travis to work.