In message <e420538c52.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> I dont know if unixlib's version of fork() does this "copy on
> write" or not, or any other details,
As I mentioned in another mail, UnixLib's implementation is rather
simple here. It just temporary moves parent out of the way (but in
the same application workspace), runs the child and then you have
the return to the parent.
> 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.
IMHO you're drawing the wrong conclusion. fork+exec on its own is not
causing any unstability by definition. It is just for your case hitting a
currently unknown problem. That might be in your program, use, setup
and/or in UnixLib. As long there isn't attempt made to drill down to the
real issue, we're unable to draw any valid conclusion at all.
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment