Re: Re: GTK 'unload'ability

[Tim Janik <timj gtk org>]

On Wed, 15 Sep 1999, Eyal Lotem wrote:

> On Tue, 14 Sep 1999 05:34:32 +0200 (CEST) Tim Janik <timj@gtk.org> wrote:

> > i'm sorry to tell you Eyal that this is uttely impossible.
> > gtk (and glib) allocate huge chunks of static data that no reference
> > counting is performed upon, and do lots of other non-revertable
> > stuff (whithin the scope of a programs lifetime).
> > being able to unload gtk, gdk or glib has just not been within the
> > initial design goals and would require a nearly-complete rewrite
> > of the libraries in question, _as well as_ any code that actually makes
> > use of them (i.e. *all* gtk programs out there).
> > patching the atexit() handlers is just a sad attempt at preventing your
> > program from segfaulting when you immediatedly exit after "unloading".

> I'd like to make a few points:
> First, existing programs that do unload GTK by simply exiting are OK and
>  will stay OK with this change,  they will NOT have to be rewritten in
>  order to make them unload GTK properly upon exiting.

you can't call this "unloading" gtk, it is the entire process context
(and space) that gets removed, there is no particular "unload gtk now"
functionality performed there.

> Second, avoiding the seg_fault at the end, while not freeing everything
>  the kernel would free when the program exits IS better than nothing.

maybe i wasn't clear enough here, to even get unloading to reliably work
would require more changes than your patch does. for instance gtk used to
also setup glib handlers that may well be triggered after unloading of the
libarry has been performed. i'm actually not sure whether we still do that,
but even if that is not the case i wouldn't want to impose this new
constrain for programmers to adhere to, since it would impose significant
extra burdens, e.g. haveing per-object and per-class callbacks that just
make sure that no pending handler references are left.
as another example, gtk modules (especially automatically loaded ones)
come with even more issues, here it'd be third party code that would have
to clean up handler references.

>  If GTK will have to be changed to be able to revert all changes later,

maybe i wasn't clear enough here either. gtk will definitely not be changed
to support unloading (of itself or of its modules), because that's just way
beyond its scope. the required changes would have such a huge impact, that
you'd better rename the whole toolkit in the same run.

>  that is fine too, but as a not-so-sad attempt to fix things, getting
>  rid of the Seg Fault is an OK solution for the midtime..

it is indeed a "sad attempt" at preventing the segfault, because it
may or may not work, depending on what library version or theme you
are currently using, and depending on how soon you exit after "unloading".
as i said before, it's not only the atexit() handlers that need to be cleaned
up, and thus your probably have a >80% chance of still segfaulting, given
that you just stay alive long enough.

considering that you don't care about the actuall memory being freed anyways,
and that the plain library code will be shared amongst different applications
anyways, why don't you simply implement your "unloading" functionality as

void
unload_gtk (void)
{
  /* do nothing */
}

and don't bother anymore?


---
ciaoTJ