Boost logo

Boost :

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-06-16 12:02:48

> Hi Klemens,
> We have been using the Boost.Process state from Boris Schäling for more
> than 3 year in productive use on linux embedded devices, and one thing
> that we had to change is to use vfork instead of the fork function.
> The problem with the fork + execve is that it produce a RAM copy of the
> process page, while vfork+execve just don't. And when the parent process
> launching child is pretty big, imagine a jvm using some jni library
> using Boost.Process... it duplicates the whole Jvm im RAM to then
> deallocate all at the moment of execve. vfork doesn't have this issue on
> linux.
> Without the use of vfork, you end up in situations where you get the
> following error: `boost::process::detail::posix_start: fork(2) failed:
> Cannot allocate memory`
> I think changing from fork to vfork is not much and brings alot of
> advantages, but one must be aware that at_fork handler won't be called.
> But this is not important as fork is used to do execve afterwards in
> Boost.Process.
Hi Damien,

I appreciate your problem, but I am not sure it's that easy. There's on
major problem: vfork is removed from the posix standard as of
POSIX.1-2008. And I'm trying to conform to posix, not linux.

So I guess, I wouldn´t use vfork as default, but it might be possible to
add a property, which will cause the library to use that. I.e. you write:

boost::process::child c("java.exe", "overhead.jar",

But I'd need to be able to check if vfork is available, so I can disable
the property if not.

Would that be sufficient for your problem?

Btw.: if you have any particular experience, that might help me improve
things, please share it. I'm always interested in that; the current
state is just based on how I'd use it.



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