What should be in SharedUnixLibrary
theo at markettos.org.uk
Thu Dec 20 02:44:16 PST 2001
On Wed, 19 Dec 2001 17:04:23 GMT, peter at chocky.org said:
> With respect to the comments in recent days from Ian, Nick, John, Justin
> and myself, there's a question of what, in the long term, we might put
> in SharedUnixLibrary.
> Let the ideas begin.
Firstly a couple of thoughts on the current module. I think the filename
needs to be changed to one =< 10 chars (maybe ShrdUnxLib), because otherwise
RO 3 people might get into problems with filename truncation (eg SysMerge
looks at copy in archive with full filename, and sees it different from copy
in !System with truncated filename, even though the version on disc is
newer). Also, psychologically, perhaps a version number of 0.something might
be better because in my mind it reflects better the temporary,
not-quite-there-yet status of it. But perhaps that's just me.
Regarding the implementation, I think avoiding the Toolbox mess is vital. If
app A uses the toolbox, it loads the relevant modules. Then app B comes
along, and needs a newer version of the modules. They are there on disc
(maybe have just been installed, or there are multiple copies on disc), but
because app A is already using the toolbox it can't load newer modules.
Also, even killing all the apps using a module doesn't help because other
modules (Window, Iconbar etc) depend on the Toolbox module. I'm not sure how
to implement that (knowing not too much about UnixLib internals), but some
way towards it would be useful.
If the above was solved, one idea might be to embed the module in an
application binary. So you can still carry individual binaries around, and
they can sort themselves as needed on machines not having the module in
!System, or a too old module. This would need extra memory in the
application slot, however, unless it could be rescaled downward somehow
(maybe a modified version of squeeze, that spawns the module then unsqueezes
the application into the space occupied by the module - but that's getting
As far as the multiple versions problem is concerned, I think we're going to
hit problems splitting the implementation between module and application. If
stubs A.AA is bound to module B.BB, what happens if some data structure has
changed between the two versions? At the moment we've got free reign on
changing internal data structures, but this would force them to crystallise.
So splitting off some non-data-structure-dependent parts would probably be
the first - but I don't know enough to suggest some.
Those are some random thoughts, having not done too much stuff with UnixLib
internals, so feel free to pick holes in them if necessary...
Theo Markettos theo.markettos at cai.cam.ac.uk
Liphook theo at markettos.org.uk
More information about the gcc