This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is there any reason to use vfork() ?


On 13/05/14 17:47, Michael N. Moran wrote:
On 05/13/2014 10:59 AM, niXman wrote:
pinskia 2014-05-13 18:47:
Can you share more information about this env.
This is specially built distributive used for micro-pc.

It might be a bug not in gcc.
I'm sure that the bug not in the GCC. After I wrote to this
ML I made sure that freezes any program using 'vfork()'.
I'll deal with it ...
I just wanted to understand the reasons to use 'vfork()'
instead of 'fork()'.

I cannot speak for GCC, but I work with embedded Linux
systems and we use vfork() to reduce the memory footprint
of child processes. When a process is created with
fork() it's memory footprint is the same as the parent
process (copied page tables). The same is not true with
vfork().

This is particularly important in the embedded systems
space with limited RAM.

Consider the system RAM requirements for a parent process
with a large RAM footprint that needs to spawn a child
process with an otherwise much smaller RAM footprint.



It can also make a big difference if the MMU is limited, or slow to work with (as can be the case in embedded Linux systems), since you don't need copy-on-write for vfork(). This is particularly true for ucLinux on embedded systems without an MMU, in which fork() does not exist and you have to use vfork().

Of course, you are not likely to run gcc on such systems.

However, I believe that vfork() is much more efficient than fork() on Windows, because Windows does not have a proper fork() equivalent. If I am correct in this, then this would make a big difference to Windows-hosted gcc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]