Re: shared "system" libraries

[Marcus Brinkmann]

At Sun, 11 Dec 2005 19:53:37 +0100,
Marcus Brinkmann wrote:
>  
> >   2. A shared library should be retained until its last client
> >      lets it go.
> >
> > But I think that the storage payment issue is actually not a problem. In
> > practice, when we install applications on a machine, they either come
> > from system-wide storage or per-user storage. If the application is
> > shared, it comes from system-wide storage. As long as this is true, we
> > simply need a "registry" for tracking shared library dependencies. It is
> > *not* necessary for every application to have its own copy of read-only
> > code.
> 
> The problem I see is that tracking the shared library dependencies has
> not to be done for the installed packages (only), but for the actual
> running program (application) instances.
> 
> Until I am missing something, this means reference counting.

Actually, if we expand the discussion from shared libraries to files
and packages in general, and if we do use per-process name-spaces,
then it seems to be that you want to do reference counting at a
"package-version" granularity.  Say a user runs a long-running shell
script, which invokes a certain set of programs once in a while (say
every hour).  Then you want to retain the specific versions of the
packages that the shell script sees (and wants to use) for the whole
run time of the script.

This means that reference counting is now not done at the "map copy"
level of individual files, but at the "package-version" level of
process filesystem namespaces.  Because process filesystem namespaces
are potentially dynamic and more or less an abstract concept anyway, I
think we have now moved far into the area where what actually should
happen is defined by policies and contracts rather than technical
features.

Ie, if a user or process registers for use of the package foo with
version A.B.C, then the system should keep that package version around
as long as the user claims to need it, or until the sysadmin wants to
break out of the contract and revoke the resources forcibly.

The more I think about it, the more important I consider the property
that the package-versions are actually kept around independently of
"virtual copies" of memory regions.  Unless of course the per-process
filesystem union boils down in the implementation to be just that (a
virtual copy of some memory region).

Of course, you still want to do reference counting.  Ie, you should
get a reference for a package-version when "mounting" this
package-version into your processes' union filesystem.  Then we can
simply require that you hold this reference as long as you need the
files (for example for shared library mappings, or for something
else).

Thanks,
Marcus