[Mono-devel-list] Proposal: Library Loading

[Paolo Molaro]

BTW, today I finally wrote the few changes needed to support
per-assembly config files as was planned from the beginning: people may
want to read the past discussions on the subject to avoid having to
rehash issues already addressed.

On 04/14/04 Michal Moskal wrote:
> Why should I use the cold cache? It will be hot after the first
> application using mono starts, and will remain hot if there are more
> such startups. The hot cache is simply the typical case when we care
> about startup performance.

The issue is that not all the people have fast computers with large
amounts of memory. When memory is tight the cached files get discarded.
In general, the typical case is in-between cold and hot cache and
unfortunately on slow computers with little memory where startup cost is
seen the most, the cold cache behaviour tends to prevail.

> I believe the memory requirements are no bigger then for single
> configuration file. You just need to concatenate the files (using custom
> file reading function for XML parser) and parse the result. Of course
> spawning separate XML parser for each file would eat more memory.

The latter is just a temporary use of memory and I'm not too worried
about that. The data from the config files needs to be kept in memory,
so loading 50 files when just one is needed is going to require more
memory.
That said, I didn't see any explanation why loading all the files in
the first place would be useful and I can't think of a single reason
myself, so it's worthless to talk about its costs if there is no
benefit:-)

> Anyhow, there are two problems with separate program: a) it needs to be
> written and maintained :-), b) you need to run it from %post script in
> case of RPM (or whatever else for other packagers). These scripts are 
> now empty, so packaging is a bit easier (no extra dependencies etc).

I dont think we should use a program to install the files, just putting
them in etc/mono/somedir is easy enough. Alternatively, gacutil can take
care of installing the config file for assemblies in the GAC.

> Having said all that, if there will be need to run gacutil from %post
> anyway, then maybe it is possible to join mlibmap into gacutil, making
> it simply GAC implementation detail. Maybe even there is no need for
> separate .libmap files -- we can use custom attribute in assembly
> itself.
> 
> BTW the generated file should not be kept in /etc, since users shall
> not edit it.

We don't use custom attributes also because they don't allow the user to
edit them:-)
The current code in cvs will try to load:
	assemblyfilename.config
	sysdir/assemblyname.config // with variations to support different versions
	userdir/assemblyname.config

When we'll deal with multi-arch support, the userdir will likely have
an additional $arch directory in the path (i386-linux, powerpc-macosx,
etc).

On 04/14/04 Jonathan Pryor wrote:
> This isn't entirely correct/possible.  App.exe.config files only apply
> to .exe assemblies, not .dll assemblies.  Which means that gtk-sharp.dll
> can't have a .config file associated with it.  At least, not under .NET.

Since the MS .net doesn't care about dllmap, that is not an issue.

> I think it would be very impractical to require each application to
> specify which library versions its dependent assemblies require, as the
> application authors don't want to know; they just want the assembly to
> work. :-)

With P/Invoke the assembly writer knows which version of the shared
library he programmed against, so he needs to specify the version/soname
(hi mike!).
Of course, programmers that just use that assembly don't need to know
the details.

> We have Mono, Portable.NET, and Rotor on Unix-like platforms.  Each of
> these (hopefully) needs/intends to solve this problem, so a solution
> that distributors/packagers could use that would apply to all of them
> would be useful, to help minimize duplication.

The Rotor people can speak for themselves, if they are listening and are
interested (since they didn't until now my guess is that they don't care).
As for P.Net, at the time I tried to coordinate with them with little
success (and can we leave it at that? Thanks).

> I now think a one config file (.libmap file) per assembly approach is
> more sensible, with the added benefit that it solves Michal Moskal's
> issue -- different assemblies could load different library versions and
> things could "just work".  I don't think the current
> $prefix/etc/mono/config file can solve this particular problem.  The

If people read the past discussions they'd have read that the
per-assembly config file was considered from the beginning: it wasn't
implemented only because I had other things to do, it was not yet really
needed and people like to argue about it more than writing the code.
It's in cvs now.

On 04/15/04 Vladimir Vukicevic wrote:
> Side note: is XML really the right thing for this?  We're talking about 
> a simple key,value mapping.  I realize that being able to eXtend it 
> later on without breaking current consumers is important, but really.. 
> wouldn't "libgtk.dll=libgtk.so.2" or even (slight *shudder*)
> 
> [default]
> libgtk.dll=libgtk.so.3
> [myapp]
> libgtk.dll=libgtk.so.2
> 
> be sufficient, and be friendlier to startup times, if we're trying to 

No, that syntax is not sufficient (not even to implement the current
capabilities).

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better