Re: Re: GTK 'unload'ability

On Tue, 14 Sep 1999 05:34:32 +0200 (CEST) Tim Janik <> wrote:
> On Mon, 13 Sep 1999, Eyal Lotem wrote:
> > Hello,
> >  I've been wanting to be able to unload the GTK library, but it has been
> > impossible due to the use of the 'atexit' function as the only unloading
> > method.  I would really appriciate it if someone added support for
> > uninitializing GTK without actually exiting the program,  which is quite
> > simple:
> > - Rename gtk_exit_func to gtk_uninit, and make it global (in gtkmain.h)
> > - Rename gtk's initialization function to name_real, and have it accept a
> >   parameter whether to 'atexit' or not.  Then have the init function
> >   (gtk_init_check if I'm not mistaken) call that initialization function
> >   and tell it to use atexit.  But also globalize the initialization function
> >   that can use NO atexit,  so it is possible to uninit GTK without exiting.
> > If someone applied this patch to the CVS tree, I'd appriciate it...
> 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.
Second, avoiding the seg_fault at the end, while not freeing everything the kernel would free when the program exits IS better than nothing. If GTK will have to be changed to be able to revert all changes later, 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..

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