Article on Unixlib

John Tytgat John.Tytgat at
Mon Jan 10 14:46:30 PST 2005

In message <3f4a3c2b4d.ajw498 at>
          Alex Waugh <alex at> wrote:

> In message <41DBE79F.6010600 at>
>           Alex Waugh <alex at> wrote:
> > For a while now I've been intending to make more use of the SUL for 
> > improving fork(), and have spent a while thinking about the best way to 
> > implement the interface to the SUL. I don't think SWIs are the best 
> > option, and I'll try and find time within the next week to explain a bit 
> > more.
> There are two main problems I'm trying to solve:
> fork() just maps to vfork(), and therefore if the child program
> alters anything in memory, or unwinds the stack, then the parent has
> problems when the child returns.
> If the child calls exec(), then the new program finds its environment
> by poking about inside the __u struct of its parent, which is not very
> nice and breaks every time __u changes, or various other
> internal structures change.


> Also, I'm not convinced that the code to set and retore handlers with
> OS_ChangeEnvironment is entirely correct in all circumstances, although
> I can't see anything specifically wrong with it. I hope to simplify
> this which may flush out any remaining bugs in this area.

I wasn't aware of any bugs in this area.  You have more info ?

> My plan is to have SUL store all data that needs to be shared between
> processes, so that a child process doesn't need to poke around in the
> parent for anything.
> Issues
> You can only have one version of the SUL loaded at once, so it has to
> be able to cope with programs compiled with different versions of
> UnixLib.
> Any code in SUL has to be written in assembly.
> I want to keep the amount of assembler needed to a minimum.

I'm currently doing some experiments with the fork() & friends code
myself.  The problems I want to solve are working popen(), pipes and
really be able to spawn a new process as a new RISC OS process when the
parent runs as TaskWindow or even Wimp task.  I haven't crystalised
out all details and how far I would like to go.  I have some prototype
code running but I too do see more use of the current SUL as central
keeper of job specific data.

It is a bit difficult to state the following without having concrete
plans but my feeling was that we better are first in a position to build
RISC OS modules with gcc before attempting to move specific job data,
file handles, etc to SUL instead of all hand coding.  Otherwise, we
are force to write everything in assembler and maybe because of this,
we're only doing half-job.

> A SWI interface could be quite slow if it is needed to access
> regularly used bits of data such as file descriptors.

SUL creating a process structure on behalf of the client (then also
be able to support multiple process structures if we have to change
its layout for whatever reasons).

> A SWI interface for implementing fork() wouldn't work because it would
> need to return from the SWI twice.
> Any code implementing a SWI will be running in SVC mode, which I want
> to avoid as much as possible.

There a lots of ways to address those items :

1. Would a fork() doing a Wimp_StartTask help ?
2. SUL could make a set of user mode callable routines available instead
   of real SWI routines.
3. SWI code can drop into USR (and back to SVC).

> The general idea is as follows.
> [...]
> Comments welcome.

Quite ambitious plan and looks very reasonable as start for a
discussion :-)

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at                             ARM powered, RISC OS driven

More information about the gcc mailing list