Re: Introducing "toggle references"

[Tim Janik <timj gtk org>]

On Mon, 25 Apr 2005, Owen Taylor wrote:

> (Why not g_object_toggle_ref() and g_object_toggle_unref()
> to match g_object_weak_ref/unref()? they sound too much like they are
> toggle the reference rather than add a "toggle reference.")

wouldn't it be better to call it toggle_link then, to make it less 
similar to other *_ref() function names (which established the notion
of a referencing action)?

> The big question is how to implement this efficiently. If we
> implemented it like g_object_weak_ref(), then we would have to do a
> qdata lookup each time the reference count of any object went from
> 1 => 2 or from 2 => 1. Which is prohibitive.

just a note, i don't think the lookup is prohibitve if we know we're
dealing with a toggle referenced object.

> Other ideas:
>
> - We could squeeze two flag bits into object->qdata by
>   using the 4-byte alignment. This would require modification
>   of g_data_list_*() to mask out the bits.
>
>   Then we could use one of the flag bits to indicate whether
>   there were any toggle references present.

[...]
the remaining items you mentioned would increase the per-object size
for struct GObject in general. at this point, there's not just Gtk+
using GObject, so i'd like to strengthen the point that the effective
memory size per GObject is not intended to grow any larger in *any*
future version (that being the case since 2.0 actually).
simply so that GObjects can be used as the "samll" objects they
currently are (in arrays, pools etc.) with a guaranteed calculatable
memory overhead.

> Not really happy with any of these. The first approach though
> ugly, would have the highest efficiency.
>
> In terms of the overall scheme, the main problem that I know
> with it is that it can't handle the case of two language
> bindings referring to the same object:
>
>        Language Runtime A                Language Runtime B
>                            |           |
>                            |           |
>                    Proxy <--- GObject ---> Proxy
>                           --->        <---
>                            |           |
>
> Is still uncollectable.

so then, why not introduce add_/remove_ proxy_link (or proxy_ref) then,
which notifies on the transition
ref_count>n_proxy_links => ref_count=n_proxy_links ?

objects kept alive purely by proxy links shouldn't be interesting
to language bindings, so they can drop their proxies with ref_count==1.

the idea being, that objects kept alive in one language environment,
only by means of a variable or similar reference, will have to go through
some gtk+ or otherwise auto-proxy-creation API point to again become
visible in another language environment. 
if there are solid reasons (non variable references from one language
environment) to keep the object alive, there are non-proxy references
on the object (container references, window list references, etc.)

regarding the implementation, you use your bit to indicate n_proxy_links>0
and store the actual number of proxy references with the proxy notify
array.

> It also can't handle cycles that go through multiple GObjects:
>
>                             |
>                  Proxy A  <--- GObject A
>                     |      --->  /|
>                     |       |     |
>                     |/      |     |
>                  Proxy B  <... GObject B
>                            --->
>
> But I don't know any way of handling these situations, so I don't
> think they are worth worrying about. (The existence of an explicit
> gtk_widget_destroy() is largely to handle the second situation.)

i don't think we shouldn't worry about a situation just because we
don't yet know how to handle it (i.e. i don't follow your logic here).
but i do agree that the second case with multi-object cycles is best
handled by means of g_object_dispose(), it was introduced for that purpose.

---
ciaoTJ