Article on Unixlib

Alex Waugh alex at alexwaugh.com
Thu Jan 13 14:38:33 PST 2005


In message <81fd542c4d.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <67474b2b4d.ajw498 at caramel.cp15.org>
>           Alex Waugh <alex at alexwaugh.com> wrote:
> 
> > 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:
> > > 
> > > [...]
> > > > 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.
> 
> I don't think I've seen this behaviour before but I would indeed suspect
> something wrong with the environment handlers because closing
> the taskwindow means calling the Exit handler.  If that aborts or loops
> (e.g. the DataAbort handler is deregistred but the Exit handler issues
> a DataAbort, then the default DataAbort handler will be use which invokes
> the Exit handler again...), the game is over (I assume the
> pointer/interrupts still work, right ?).

I can't really remember, but I think the pointer still moved.

> If you have some code showing this behaviour, I wouldn't mind helping
> finding the underlying problem.

I most recently saw this on ogg123, whilst I was trying to find a
pthreads bug. But once I'd fixed the pthreads bug, the problem
disappeared. Whether this was cause or effect I'm not sure. 
bug #137 also partially sounds like a similar type of problem.

> > [...]
> > > 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.
> 
> I'm not convinced that just moving that part of the current assembler code
> to SUL will result in a better code.  I'm just afraid it will even become
> more difficult to follow how things work and put a burden on SUL to remain
> and support this interface for the new UnixLib static compiled programs
> for quite some period.

I think it will result in clearer code. There will be less messing
with shifting pointers around when moving the program to the top of the
wimpslot. It will be a lot clearer which structures contain information
used by child processes (have you tried working it out from the current
code? It is a scary amount).
I think it will also be simpler conceptually. The boundary between the
program and SUL will be more like the boundary between the program and the
OS in Unix, in that the program will only have to worry about managing
itself, and SUL will take care of any interaction between programs.

> The moment we have UnixLib as a dynamic library this becomes less of an
> issue as making incompatible changes in the dynamic library can go
> together with an update of SUL.

I think dynamic libraries is a completely separate issue, and won't
have any effect on SUL. While minor bugfixes to UnixLib would allow you
to replace the shared library, anything that caused a change to the ABI
of the library would require programs to be recompiled against the new
library, therefore you still need the old shared library present for the
old programs to link to. Hence the situation is exactly the same as for
statically linked programs - the SUL will have to support a range of
UnixLib versions in either case. With a well designed process structure
and interface, I don't think this will be too much of a burden though.

> > 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.
> 
> You're right, so that means no (or not a big) dependancy on the module GCC
> work.
> 
> > > [...]
> > > > 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
> > parent.
> 
> Apologies for my reasoning being a little bit jumpy but if we have fork()
> working so that the new child becomes a separate Wimp task, then we don't
> need the moving data/parent code anymore and we don't need to deregister
> the parent environment variables anymore.
> 
> If Wimp_StartTask returns a non-zero value, we have a child which is
> another Wimp task happely running.  By monitoring Message_TaskCloseDown
> or service call WimpCloseDown, we could know implement things like wait()/
> waitpid().
> 
> An exec() of a vforked child could use a similar Wimp_StartTask
> implementation.

This would only work for program in taskwindows, so unless we dropped
support for non-taskwindow programs then we'd still need the code to
move the parent in addition to any new code. 


Alex

-- 
Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/



More information about the gcc mailing list