Boost logo

Boost :

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 :
> 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 - 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 does fork+exec, which
> has been changed after because of similar issues:
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at