Article on Unixlib
alex at alexwaugh.com
Mon Jan 10 15:25:55 PST 2005
In message <66ab472b4d.Jo at hobbes.bass-software.com>
John Tytgat <John.Tytgat at aaug.net> wrote:
> In message <3f4a3c2b4d.ajw498 at caramel.cp15.org>
> Alex Waugh <alex at alexwaugh.com> wrote:
> > In message <41DBE79F.6010600 at alexwaugh.com>
> > Alex Waugh <alex at alexwaugh.com> 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 ?
No, just a vague suspicion really. Occasionally, a program in a
taskwindow has got into an infinite loop somehow, with escape having
no effect, and if you close the taskwindow then there is a complete
machine freeze. It is entirely possible however that this is unrelated
to the environment handlers.
> > 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.
I think building something along those lines on top of my proposal would
be possible, and significantly simpler than building it on top of the
> 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.
I don't think this is the case, because:
I don't intent to move that much code into the SUL. If the process
structure is well defined and extensible then most of the code to
access it can remain in UnixLib.
The two main bits of code I want to move into the SUL are the
environment handlers and the fork/exec code, both of which are
currently written in assembler, and probably will have to remain so.
If the SUL code is called as APCS routines, then it could be written in
C and compiled as non-module code. It would only need to be module code
if it was accessed directlty from the module, e.g. as SWI calls.
> > 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 ?
In what way? If fork() is implemented by calling a SWI, then that SWI
would have to return to the child program, then when the child has
exited somehow jump back into the SWI and return a second time to the
> 2. SUL could make a set of user mode callable routines available instead
> of real SWI routines.
Isn't this more or less what I'm proposing?
> 3. SWI code can drop into USR (and back to SVC).
It can, but why then bother with the overhead of a SWI call?
Alex Waugh alex at alexwaugh.com
PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/
More information about the gcc