[Mono-dev] Use eglib as a default for mono 2.6

[Paolo Molaro]

On 04/23/09 Miguel de Icaza wrote:
>     The cons are:
> 
> 	* We still need to deprecate/break the API for the functions
> 	  listed in [1]

At some point we need to break API/ABI anyway, since it's required for
the new GC, we need to hide some implementation details that are
currently exposed, like MonoArrayType, MonoMethodSignature, MonoType
itself, MonoTypeNameParse, MonoArray and a few ugly API entry points.
We need to coordinate to break the API/ABI just once for all the needs,
we can't break it 2-3 times.

> There are still a handful of places where glib is better than eglib,
> tiny bits here and there, but nothing really major.

There are several reasons for having our own code, in no particular
order:
*) remove a dependency which is getting bigger every day
*) being able to inspect inside the data structures (GHashTable for
example is opaque and several times I needed to inspect it for
debugging; in other cases we'd need to check if the hash distribution is
good and we can't with GHashTable)
*) GLib doesn't support some APIs we need: a GHashTable foreach that can
be early-terminated is one example, we currently waste time visiting it
all even if we found what we were looking for.
*) we'll never be able to control out of memory cases with glib since it
just dies. This can happen in many cases even if plenty of memory is
otherwise available for recovery or graceful handling.
*) glib installs a compiler-specific file, so the same compiler must be
used for mono and glib (this mainly confuses the solaris users, but there
are also other cases)
*) mono can't be used as a plugin in single-threaded apps that use glib
(glib inited without threading support-> we die)
*) we need about 50 kb of readonly text section to implement the
features we need, just linking with glib brings 20 KB of writable
memory and several pages of text.
*) we really just use a tiny subset of glib the API/ABI break is a good
time to switch for the above advantages

> We could also make sure that the structures map 1 to 1 to the Glib
> structures for the ones that we use, that would prevent the need to even
> break the API when using the remapping macros. 

It doesn't matter, we need to break the API/ABI anyway and such hacks
are better avoided.

> But I can see why this last one might make some people uncomfortable.
> 
> [1] This is the list of public API entry points that expose Glib data
> structures.
> 
> metadata/assembly.h:void      mono_assembly_foreach    (GFunc func, gpointer user_data);
> metadata/verify.h:GSList* mono_image_verify_tables (MonoImage *image, int level);
> metadata/verify.h:GSList* mono_method_verify       (MonoMethod *method, int level);
> metadata/verify.h:void    mono_free_verify_list    (GSList *list);
[...]

There are others, like the ones exposing MonoTypeNameParse, plus all the
ones where one is supposed to free results with g_free().

As for the cases where glib might be faster than eglib (small struct
allocations, for examples) it's likely that we should optimize mono not
do abuse them, because if it's significant in the overall time for mono
apps something looks wrong.

lupus

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