[gccsdk] fork() call failing
beeb at woosh.co.nz
Sun May 23 15:45:25 PDT 2010
In message <691f591b51.Jo at hobbes.bass-software.com>
John Tytgat <John.Tytgat at aaug.net> wrote:
> In message <1d41e01851.beeb at ron1954.woosh.co.nz>
> Ron <beeb at woosh.co.nz> wrote:
> > In message <ed3dcc1851.beeb at ron1954.woosh.co.nz>
> > Ron <beeb at woosh.co.nz> wrote:
> > > While having no problem calling fork() from small demo programs,
> > > it allways fails when being called from within the execsh()
> > > function. (unix mk program)
> > > I can call system(), which uses fork(), I read somewhere.
> > > I can use vfork(), but it is has functional differences which
> > > are hard to get around, like it cannot return to
> > > the caller of execsh().
> > > At the end of execsh() is
> > >
> > > return pid
> > >
> > > With pid = fork, pid can be either 0 or the child process ID,
> > > depending on which process is looking at pid.
> > > This doesn't happen with vfork().
> > >
> > Actually it does, after the child encounters _exit(0) the
> > Parent is unhalted and it -does- proceed in the normal fork()
> > fashion. I might get vfork() to do what's needed yet.
> If a child process is started by UnixLib, the parent will be moved away
> to make room for the child, the child runs until it exits, the parent
> gets moved back to its original place and it continues.
> For all clearness, this is all happening as one RISC OS task so parent
> and child will not run at the same time.
> I think this is confirming what you're seeing as well.
> > The executing of TaskWindows may turn out to be a bigger
> > problem.
> I'm confused why you're mentioning TaskWindow here. When using fork()/
> exec*() etc, the UnixLib behaviour is the same if it is run under TaskWindow
> or as standalone task (with or without Wimp_Initialise).
> > /bin/sh is converting to a Taskwindow, I've just had instability
> > and module space errors so far.
> I don't think this is UnixLib related. If you expect to launch a 2nd
> TaskWindow from a 1st TaskWindow, please make sure it works without any
> UnixLib involvement first: type "TaskWindow ex" in a TaskWindow. Does
> this work ? Here on RISC OS 6 I get a 2nd TaskWindow opened with the
> contents of my current selected directory. I seem to remember this didn't
> work in RISC OS 4 (and presumably neither in RISC OS 5).
> But even if this works, I don't believe UnixLib supports a child being
> executed under another TaskWindow (it would be nice and perhaps not even
> so difficult but I haven't investigated this).
The run file wanted to open a machine shell in one routine and
pipe the command in a second routine.
I run into strangeness trying to satisfy the first routine,
through trying different things.
I have found bypassing the shell initalising routine completely
and just using the pipecmd()and its execvp() call is working.
The vfork() is working, I actually have a fully working
program for testing now. I will post again with details.
More information about the gcc