On Fri, 25 Nov 2011 14:37:27 +0000 Norman Gray <[email protected]> wrote:
> > Maxence, hello. > > On 25 Nov 2011, at 14:16, Maxence Guesdon wrote: > > >> > >> 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. > > > > That is: > > - when you retrieve an already existing object (with a foo_get... function > > for > > example), you make a copy and make the gc call the free function on this > > copy when the value is no more reachabe, > > I typically wouldn't make a copy in that case, since most of these cases are > documented to return a new librdf object. That's a new object in the sense > that it is the caller's (ie my) responsibility to free it when it is no > longer needed. > > In some cases, the library documents that the object (or string, or whatever) > is a _shared_ object. In this case, the caller must not free it. In this > case, I explicitly make a copy using, say, librdf_new_uri_from_uri: that > returns a 'new' object, which is what I wrap in a scheme object and return. > Now, internally, this librdf 'copy' may be the same as the original, but with > an incremented reference count, but that's nothing to do with me. > > > - when you create an object, you don't make a copy, but you just embed it > > in a racket value. > > That's correct. The created object is (implicitly) documented not to be > shared, so that it's my responsibility to manage it and free it when > necessary. > > > Is so, that's the way I began to before being afraid of freeing objects > > still in use. I wasn't aware of the counter already used internally. > > You shouldn't need to be aware of the counter used internally. As long as > you don't attempt to call librdf_free_* on an object documented to be shared, > but do call librdf_free_* for every object that's not documented to be > shared, you should be fine. > Thank you, it now seems very clear to me (and kinda simple to implement). Regards, Maxence _______________________________________________ redland-dev mailing list [email protected] http://lists.librdf.org/mailman/listinfo/redland-dev
