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.
