Maxence, hello. On 25 Nov 2011, at 12:09, Maxence Guesdon wrote:
> My first guess was to make my own counter for each redland structure > pointer, then decrement this counter when the ocaml value embedding the > pointer was reclaimed by the Gc (when it becomes unreachable). > But since I'm not aware (from the ocaml side) of internal way of handling, > for example, nodes in a statement, I may free, for example, a node even if > it's still referenced internally by a statement. > > Since there is a kind a recursive freeing, I may just don't care about C > structure pointers and let the developper use the free functions himself. I think that part of the point of using a GC language is to free the developer from having to mess about with low-level rubbish like free functions. My approach in the Racket library was to make a thin-as-possible Racket layer around the C library, which is in turn wrapped by a Racket layer which exposes the resulting objects in a more scheme-ish fashion. So in the wrapper layer, I return scheme objects which encapsulate the librdf structs (librdf_uri, librdf_node, and so on) that come back from the functions called. These structs are therefore conceptually 'owned' by the Racket layer, so where the librdf documentation notes that a returned object is shared, I make a copy of it using one of the librdf copy-create functions. The only place where I recall that came unstuck was in the bug reported in <http://bugs.librdf.org/mantis/view.php?id=478>, where one of the copy constructors turned out to be a shallow copy rather than a deep one. The Racket FFI allows me to associate a 'custodian' with each scheme object the library creates. The custodian encapsulates code that is run when an object is freed by the GC, and that's where I can run librdf_free_* functions, without the user being troubled by them, and without me having to worry about reference counting. I would imagine the OCaml FFI would have a similar capability. Best wishes (and good luck), Norman -- Norman Gray : http://nxg.me.uk _______________________________________________ redland-dev mailing list [email protected] http://lists.librdf.org/mailman/listinfo/redland-dev
