closure floating

[Havoc Pennington <hp redhat com>]

Hi,

Speaking of floating, GClosure doesn't actually use ref/sink/unref
like GtkObject - it just has refcount starting at zero, implemented
with a "floating" flag. But the user-visible behavior is exactly the
same as refcount start at 0, and has the same problems that led to
using ref/sink instead of initial 0 refcount with GtkObject.

i.e. this code is broken:

    closure = g_cclosure_new (func, data, dnotify);
    gtk_container_foreach (container, closure);
    /* closure is already finalized at this point */
    gtk_container_foreach (container, closure);

I understand the intent is to support this:

    gtk_container_foreach (container,
                           g_cclosure_new (func, data, dnotify));

But, that has the same problem as supporting:

    gtk_signal_emit_by_name (gtk_button_new (), "clicked");

So I don't understand the special-case treatment of closure here. It
introduces a third type of refcount behavior into GLib/GTK, when
people are already confused enough about the first two.

Comment in the source code indicates that we are avoiding ref count of
0, but you may as well use ref count of 0 - the semantics are the
same:

    GClosure*
    g_closure_ref (GClosure *closure)
    {
      g_return_val_if_fail (closure != NULL, NULL);
      g_return_val_if_fail (closure->ref_count > 0, NULL);
      g_return_val_if_fail (closure->ref_count < CLOSURE_MAX_REF_COUNT, NULL);

      /* floating is basically a kludge to avoid creating closures
       * with a ref_count of 0. so the first one doing _ref() will
       * own the closure's initial ref_count
       */
      if (closure->floating)
        closure->floating = FALSE;
      else
        closure->ref_count += 1;

      return closure;
    }

Can you give some rationale for this behavior?

Havoc