From: "Robert R. Schneck" <schneck at math.berkeley.edu>
Message-ID: <1539.209.145.86.33.1125326409.squirrel at math.berkeley.edu>
In-Reply-To: <17169.62751.133861.390849 at karryall.dnsalias.org>
References: <1026.209.145.86.33.1125101422.squirrel at math.berkeley.edu>
    <17169.62751.133861.390849@karryall.dnsalias.org>
Date: Mon, 29 Aug 2005 07:40:09 -0700 (PDT)
Subject: Re: Custom Tree Models
To: "Olivier Andrieu" <andrieu at ijm.jussieu.fr>
Cc: lablgtk at math.nagoya-u.ac.jp
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

"Olivier Andrieu" <andrieu at ijm.jussieu.fr> wrote:
> Yes, when you store a caml value (allocated on the heap), you have to
> register it with the GC using ocaml_register_global_root() otherwise
> the GC may move the value and the pointer is invalidated. The problem
> with GtkTreeIter is that these are small struct, usually allocated on
> the C stack and they are copied by value sometimes. So you cannot use
> register_global_root() because the C code doesn't tell you when the
> iter runs out of scope and the copies would not be registered anyway.

Yes, I feared as much.  I am considering three ways around this.

(1) For each row, call into C to malloc a handle to the value, and
register that C location as a global root.  Then store that C location
in the GtkTreeIter.  Would all those global roots cause an absurd slowdown?

(2) Use Gc.create_alarm to keep track of a counter, which is also stored
in the iters, so that I notice when an iter is out of date.  One question
is, do values only move during heap compactions, or might they be moved
during other GC operations?

(3) Analyze GTK to determine when callbacks to OCaml might occur while
an iter is live, and then make sure the callbacks preserve iters.  No
idea whether this is possible.

Thanks for your help,
Robert