Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-06-16 19:21:06
On 17/06/2016 02:26, Damien Buhl wrote:
> 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.
Is this specifically for NOMMU linux?
MMU architectures shouldn't have this issue, as fork does a
shared-memory-copy-on-write mapping so that the pages aren't actually
duplicated unless written to, and the subsequent exec* unmaps the pages
so this never happens (other than a bit of stack).
NOMMU architectures don't support those kinds of mappings, so have to be
rewritten to use vfork instead (which is generally unsafe unless
immediately followed by exec*, unless you know what you're doing).
Although the last time that I played with NOMMU, fork used to just fail;
perhaps it's been changed to make copies of all the pages instead? If
so, that would indeed be problematic for large parent processes.