Re: [boost] [boost.process] 0.6 Alpha

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-06-17 18:54:22

> 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#tag_03_427_08
>
> 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.