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

[Tristan Van Berkom <tvb gnome org>]

On Tue, Nov 22, 2011 at 4:48 AM, Emmanuele Bassi <ebassi gmail com> wrote:
> hi;
>
> On 22 November 2011 09:44, Tristan Van Berkom <tristanvb openismus com> wrote:
>> 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).
>
> it's not strictly necessary to have a default behaviour, though.
>
> we could have two distinct functions:
>
>  /* schedules a idle source to release the resources when we re-enter
> the main loop */
>  void
>  g_autorelease_pool_pop_in_idle (GAutoreleasePool*);
>
>  /* releases the resources immediately */
>  void
>  g_autorelease_pool_pop (GAutoreleasePool*);
>
> following the pattern in GIO. for MT applications we could even
> provide a function to release resources within a specific GMainContext
> as well, to release the resources in a specific thread instead of the
> default main context.
>
> the obvious issue is: how does this interact with languages that do
> have a GC, and how does the API work to avoid making the life of
> developers for high-level languages apps and/or bindings a nightmare.
> if libraries start using this object for their internal allocations,
> for instance, or start relying on it when using their API.

Interesting idea for GIO like threaded operations to be sure, I doubt
that language bindings would be the obstacle, language bindings
generally cope with gobject apis to manage gobject ref counts and
are probably already special casing floating references (or by now
they are unconditionally ref_sink'ing *everything* and doing their
own garbage collection)...

I only wonder how to implement an API for that which makes
sense, is very simple to use and allows the author of threaded
async operations to virtually ignore ref-counting (which I think is
the point of the autorelease exercise).

I also predict some confusion when executing an asynchronous
function's top half in the calling thread... i.e. who determines that
that particular function has a separate autorelease pool target
than the default one on top of the stack for that thread ?

Also while running the top half of:

foo_bar_do_something_async ()
{
   foo = foo_new ();   // assume that foo_new() and bar_new() return
   bar = bar_new ();   // a soft reference which will be unreffed by
the autorelease pool

   /* ... do stuff with foo and bar */

   /* Save 'bar' so that it's attached to the async response */

   /* Get rid of expensively huge 'foo' right _now_, dont save it
    * around for later use in the result callback
    */
   g_object_unref (foo);
}

In this case one would presume that 'foo' and 'bar' (if created with a
soft reference)
would be added to the same autorelease pool, even if we could somehow step in
and give that function a new autorelease pool without that function
doing anything
declarative... that function will still want to decide which objects
must be saved
for the async reply.

As soon as the function starts to do something declarative to decide
which memory
lasts until the async callback, of course the whole plan becomes
useless (i.e. we already
have g_object_ref() for that).

Cheers,
        -Tristan