[gccsdk] fork/exec problems
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.
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().
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