Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Tristan Van Berkom <tristanvb openismus com>]

On Tue, 2011-11-22 at 09:03 +0100, Mikkel Kamstrup Erlandsen wrote:
> On 11/21/2011 04:54 PM, Hub Figuière wrote:
> > On 21/11/11 07:34 AM, Mikkel Kamstrup Erlandsen wrote:
> >> This is precisely my motivation for introducing this; ie. not to catch
> >> leaks, but to tidy the code. Bigger code bases almost always grow
> >> functions with multiple returns - notably when error handling is
> >> introduced. Automatic freeing can cut down on that complexity
> >> considerably. On less complex functions it can still add clarity by
> >> making the actual algorithms more apparent in between all the g_free()s
> >> and g_object_unref()s.
> >
> > Which is basically what my counter-proposal of g_object_autorelease() is
> > about.
> >
> > That's exactly the use case in Objective-C with Cocoa that, unlike C++,
> > does not have scope based life cycle of object, but supports exceptions.
> >
> > Also to make it more useful with Glib, we would need to have actually
> > containers implemented as GObjects.
> >
> 
> I am guessing that you expect this autorelease pool to trigger a garbage 
> collection in an idle call on the mainloop or something?
> 
> Assuming "yes"; I can see that this has its use cases, but also some 
> pretty huge drawbacks. Like 1) needing a mainloop, and 2) being 
> susceptible to memory ballooning with something like a for-loop doing 
> lots of string manipulations. And 2) is a very common use case for 
> automatic cleanup since looping often has a few early-breaks with the 
> required extra cleanup logic.

Auto-release pools come with a hard requirement of the user
understanding them, that being said after having used them
I can say that it's a practical and comfortable idea as specially
when compared to our floating ref solution (i.e. the floating object
is owned by noone... but somehow needs to be ref_sinked and unreffed
anyway)

So... for instance, when implementing an iterative api such
as gtk_container_foreach(), a pool should be pushed onto the
stack:

g_autorelease_pool_push ();

for (i in children)
   user_callback (child, data);

g_autorelease_pool_pop ();

Pushing a pool puts one on top of the stack, popping a
pool will release all of the references which it has
accumulated during it's life-cycle. Authors of programs
in Cocoa need to understand this and manually push/pop
autorelease pools when such memory balooning might be
a problem (again, a much simpler concept to cope with
than floating refs IMO).

Similarly the GMainLoop, by virtue of being a loop, 
should also push a pool onto the autorelease pool stack
and pop it while dispatching GSources (and this is where
you get the extra 'unref on mainloop hit' detail).

Cheers,
         -Tristan

> 
> That said, I am not against the concept either. It does have the 
> advantage on ref counted types that any function on the call stack can 
> grab a ref before the next idle. So it can work over returns and such.

Right, you can have functions that return a soft reference like so:

   return g_object_autorelease (object);

But the value can and should only be trusted in the scope of the
function calling a function which returns a soft reference (because
you never know when your original caller will pop the current pool
off of the stack, it becomes conceptually invalid after you run out
of the current scope).

Cheers,
     -Tristan

> 
> Cheers,
> Mikkel
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list