Re: GTK+ is not Valgrind-friendly

Owen Taylor wrote:
[ ... ]
But basically, I don't think a gtk_free_all_memory() is interesting;
it's a lot of extra bookkeeping for no actual benefit to apps.

On a passing note,
    there may be some other worms that can be addressed in the same can.
It would be only a short jump further to write some complementary functions
to gtk_init()/g_type_init()/gdk_rbg_init(), i.e. *_uninit() or something
to that effect.

    Although I admit I havent played around with the (somewhat recently added)
multi-display support in gtk+, from what I understand; most gtk+ function calls
assume that you are refering to the default display (i.e. the one read at
gtk_init() time). While *_uninit() functionality wouldn't allow you to easily
manage ui's on multiple "Display"s simultaniously, it would at least allow an
application to "sometimes be a UI", and arbitrarily present itself on a
requested Display, minus the fork/exec.

    This example I'm sure is very context specific (how many apps will want
to do this ?) as is the valgrind reasoning (also definitly not worth the effort
IMO), But there may be added value in allowing an app to gtk_init()/gtk_uninit()
multiple times in the apps lifetime, especialy if Paul is reporting an entire
MegaByte that can be saved between gtk_uninit()/gtk_init().

Just a passing note ;-)

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