On Tue, 2007-29-05 at 16:29 -0700, Brian J. Tarricone wrote:
> On Tue, 29 May 2007 18:12:57 -0500 Dan Saul wrote:
>
> >Good day, new to the list and GTK+ in general.
> >
> >I am formerly a Macintosh developer. Currently however I am now working
> >on Objective C bindings for GTK+. I am currently looking at the
> >documentation for the run loop which I have found located at
> >http://developer.gnome.org/doc/GGAD/sec-mainloop.html .
> >
> >My question is, I need to implement the autorelease pool's run loop
> >hook that basically runs once every run loop cycle and frees memory.
> >So far guint gtk_idle_add(GtkFunction function, gpointer data); looks
> >the most promising for this purpose. However, being new to this
> >library I would like to get the opinions of those who are more
> >experianced whether there is a better -- or more appropriate place for
> >me to put this code.
>
> You're correct, sorta. For starters, please don't use that reference
> for new gtk2-based code. That book (while excellent) is old and refers
> to gtk 1.2, which hasn't been maintained for many years.
>
> In gtk 2, gtk_idle_add() has been replaced by g_idle_add(). You can
> look at the glib reference documentation here:
> http://developer.gnome.org/doc/API/2.0/glib/
>
> I'm not entirely certain that a function added using g_idle_add() will
> actually run with every main loop cycle. It may only run when there's
> a certain level of inactivity, and you might want to use
> g_idle_add_full() to raise the priority higher.
>
> However, are you sure this is the best way to do this? Using an idle
> function will chew through CPU cycles while the application is
> otherwise idle (really hurts laptop battery performance, for one
> thing). Another option is a timeout using g_timeout_add(), but the
> correct approach would be to add a custom GSource that is only invoked
> when it needs to be.
>
> Actually, you might want to poke around in gdk/quartz/ inside gtk+
> SVN. I imagine autorelease pools are used in the MacOSX backend; maybe
> you can find some hints there as to what's best.
>
> -brian
On Tue, 2007-29-05 at 16:37 -0700, Brian J. Tarricone wrote:
> Replying to myself...
>
> On Tue, 29 May 2007 16:29:12 -0700 Brian J. Tarricone wrote:
>
> >Actually, you might want to poke around in gdk/quartz/ inside gtk+
> >SVN. I imagine autorelease pools are used in the MacOSX backend; maybe
> >you can find some hints there as to what's best.
>
> I was curious, so I looked around. It looks like the gdk-quartz
> backend allocs a new pool at the top of any function that uses
> quartz/cocoa functions (which may or may not make use of objects that
> use autorelease), and then releases the pool at the end of the
> function.
>
> Reading up on NSAutoreleasePool, it looks like they're "nestable" or
> "stackable", in that the most-recently-created pool will always get
> used when any object receives an 'autorelease' message. It sounds like
> a bit of extra work on your part, but clearly someone thought this was
> the right approach, and it feels much more correct to me than running a
> cleanup function periodically via the main loop. Are
> NSAutoreleasePools expensive to create and/or tear down? That's the
> only argument I could see against this method.
>
> -brian
I thank you for the new reference for me to look at.
NSAutoreleasePool is pretty much exactly what you read up on it being.
My motivation for creating the pool at the start of the event loop and
releasing it at the end is from the source of Apple's NSAutoreleasePool
documentation.
"NSAutoreleasePool objects are automatically created and
destroyed in the main thread of applications based on the
Application Kit, so your code normally does not have to deal
with them. The Application Kit creates a pool at the beginning
of the event loop and releases it at the end, thereby
periodically releasing any autoreleased objects generated while
processing events."
Preferably I would be able to write these bindings so that the developer
who would be using them could essentially ignore the presence of the
pools completely as it is in Apple's implentation.
Just to be sure of what you are suggesting;
function ()
{
[create pool];
// Do work.
[destroy pool];
}
Due to the stackable nature of autorelease pools this is completely
possible should the developer need it (and I have used it the past when
I had a function that created and discarded lots of small objects
quickly).
However the event loop based pool would catch anything that was missed
so as to avoid possible memory leaks.
My interpretation may be completely wrong, feel completely free to
correct me.
-- Dan Saul
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
