Re: Merging gio into glib

On Wed, 2007-11-07 at 17:45 +0200, Xan wrote:
> On Nov 7, 2007 5:35 PM, Alexander Larsson <alexl redhat com> wrote:
> > The idea is that this library would contain non-ui stuff that
> > applications want but that requires GObject, so they can't be in glib.
> > Various names for this library has been thrown about:
> >  gfoundation, gbase, gplatform
> Would it be again one module and multiple so or only one so? If it's
> the former, how does it improve things? If the latter, what about
> people interested in gio but not in gsettings (for example)?
> (Maybe I'm missing something, but the benefits are not really clear to me)

The general cost of not using part of a library are very low. The parts
not used are just not paged in. However, the cost of using two libraries
are larger. At least 4k unshared memory per library, and one extra hash
lookup for *any* symbol to resolve. 

It also means that if at some point the various libraries need to call
each other there won't be any complicated interdependency and ordering

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]