Re: [gccsdk] fork/exec problems

In message <b102448d52.Jo@hobbes.bass-software.com>
John Tytgat <John.Tytgat@aaug.net> wrote:

> 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.

Taking into consideration your point that fork() is probably not buggy,
and the fact that vfork() is working OK, and that the two methods use
the memory allocation differently, I will try some variations in
this dept.
The second day I used vfork()/exec I run into sigsev error at the point,
similar to the latest fork()/exec, but it turned out I needed a larger
wimpslot. That was puzzling because I was performing the same operation
on the same files as the previous day.
I won't rule out the possibility of running the binary in a different
manner, for example the running of Tar from an Obey file that is run
from a Taskwindow compared to running it more directly, and I have run
it from a wimptask also. Checking for results on my RiscPc 3.7 should
do things differently too.
It is less frantic trying things out now that I have a bulletproof
version using vfork()/exec (save for the guessing game for a wimpslot).

One thing that was not very manageable by using fork()/exec was the
incrementing of memory used by about 740K every time it was used.
So a program that can run in say, 1280K using vfork() alternatively
would swallow up over 32MB with 50 or so calls to fork()/exec
(speculation based on what happened in the Task display)
It is possible that tar is not closing the script file each time it
is run from the fork(0)/exec and not releasing the memory.

Thanks for your tips.
Ron M.








_______________________________________________
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