Re: Weak references for GObject

[Dan Bornstein <danfuzz milk com>]

I wrote:
>You can think of it as if [the soft ref/unref] 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.

Owen Taylor writes:
>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.

If the semantics requires prompt finalization, then I can't argue with
that. However, if you can defer finalization until the next time that it
"normally" happens (at unref/destroy time only? apologies for my continued
lack of depth of knowledge of the gtk internals), then it's no longer an
issue.

Or when you say "finalization" do you mean pre-mortem finalization, where
the contents of the object are still available to the finalization code? If
so, then, yeah, you're SOL. But (bait bait) everyone knows that pre-mortem
finalization is frought with problems, which is why everyone should be
using weak references to do finalization in the first place.

> - Defining memory being tight is hard - really hard -

Well, yeah, but you can pick a policy. Conservative is probably better to
start off with (e.g., freeing soft references before resorting to asking
the host OS for more memory), but that's the sort of thing that can be
evolved over time.

>if you wait until malloc() fails, you've probably waited too long.

Certainly. I'd think the aim would be to make g_malloc() free
softly-referenced objects *before* reporting a failure to allocate. (If
when you said "malloc()" you meant the underlying non-gtk-controlled
allocator, then I don't see how to reasonably expect that to free up soft
references, but people shouldn't be avoiding g_malloc(), should they?)

Only after all soft-reference-only objects have been freed should the
system report that a particular memory request isn't satisfiable. It's not
clear to me what the issue is that would make it hard to augment g_malloc()
in this fashion.

Cheers,

-dan