[gccsdk] fork/exec problems

Ron beeb at woosh.co.nz
Mon May 7 14:42:44 PDT 2012


In message <4ae3418c52.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <8372408c52.Jo at hobbes.bass-software.com>
>           John Tytgat <John.Tytgat at aaug.net> wrote:
> 
> > You have to be aware of fork() vs vfork() differences.  One of those
> > is that the child create with vfork() is sharing the same parent's
> > address space, while fork() makes a complete copy.  That explains your
> > observation of wimpslot size changes with fork() and also why this
> > can only happen in Wimp context.
> 
> Also the implementation in UnixLib is relatively simple, it moves the
> parent code at the end of application space, let the child run until it
> finishes and parent continues.  So this does not end up with an extra
> Wimp task, nor it allows you to have concurrently running parent & child.
> 
> John.

I found this again yesterday. quote

vfork() is an obsolete optimization. Before good memory management,
fork() made a full copy of the parent's memory, so it was pretty
expensive. since in many cases a fork() was followed by exec(),
which discards the current memory map and creates a new one,
it was a needless expense. Nowadays, fork() doesn't copy the memory;
it's simply set as "copy on write", so fork()+exec() is just as
efficient as vfork()+exec().

unquote.

I dont know if unixlib's version of fork() does this "copy on
write" or not, or any other details, just that fork()/exec has been
causing unstability in the past a (few months ago) and now with
latest svn upgrades stops program completely at the fork()/exec.
The earlier situation was erratic and I think would be difficult
to build a small test case to show it happening. It possibly is
only happening while running a largish program.   
 
I am getting a better picture of things now, for example I know
now that it is fork()/exec causing unstability, and there are 
obvious advantages to using vfork()/exec in maybe all cases.
   
Thanks,  Ron M.
 




More information about the gcc mailing list