Re: Weak references for GObject

[Owen Taylor <otaylor redhat com>]

Dan Bornstein <danfuzz milk com> writes:

> Owen Taylor <otaylor redhat com> writes:
> >If resurrection for cache purposes is considered necessary (I don't
> >consider it so), then I'd like to separate it out into a clearly
> >defined separate facility - something like:
> >
> > g_object_add_last_ref_notifier();
> >
> >That can be emblazoned with all the appropriate warnings.
> 
> Why not just do Java-style soft references? In keeping with the other
> part of your proposal, the calls would be:
> 
>  void g_object_soft_ref   (GObject     *object,
> 		           GWeakNotify  notify,
> 			   gpointer	data);
>  void g_object_soft_unref (GObject     *object,
> 	 		   GWeakNotify  notify,
> 			   gpointer	data);
> 
> where the ref call simply indicates that the system shouldn't necessarily
> destroy an object when the last normal reference goes away (until the unref
> call is made).
> 
> You can think of it as if these functions manipulate the refcount just like
> normal ref/unref, except there's a side table mapping softly-referenced
> objects to their soft refcount. When memory gets tight (however you want to
> define that), you look at that side table and find objects whose only
> refcounts are due to soft references, and those are the ones that are
> subject to immediate destruction. When that happens, the notify functions
> are called, just as with weak references.

I thought about this, but decided:

 - To make this work, it would involve calling finalizers out of
   g_malloc(), which could result in all sorts of reentrancy problems,
   locking problems, etc.

 - Defining memory being tight is hard - really hard - if you wait
   until malloc() fails, you've probably waited too long. Only the
   kernel is really in a position to judge use of memory for caching
   vs. for applications, and even that can be very tricky to 
   get right.

Regards,
                                        Owen