The following issue has been SUBMITTED. ====================================================================== http://bugs.librdf.org/mantis/view.php?id=365 ====================================================================== Reported By: normang Assigned To: ====================================================================== Project: Redland RDF API Issue ID: 365 Category: api Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2010-04-03 18:21 Last Modified: 2010-04-03 18:21 ====================================================================== Summary: Reduce/remove undocumented coupling between librdf objects (helps bindings to GC languages) Description: If an application frees a librdf_storage object, then the library complains about unfreed iterators pointing to that object. This undocumented coupling between objects imposes an order on exit-time deallocations, which can be very inconvenient when writing bindings in GC languages. This is because in such languages librdf_free_* calls are naturally squirreled away in per-object closures, and invoked by the GC.
See discussion in <http://lists.librdf.org/pipermail/redland-dev/2010-March/002058.html>, <http://lists.librdf.org/pipermail/redland-dev/2010-March/002059.html> and <http://lists.librdf.org/pipermail/redland-dev/2010-March/002065.html>. This feature request recapitulates the suggestion in the third of these. Proposal: separate out nullification of an object from deallocation of the memory. Thus nullification would be an idempotent operation which clears the state of the object and nullifies any dependent objects. A nullified object would still be valid, but report trivial state and have no coupling to other objects. The librdf_free_* functions could then consist of nullification followed by deallocation. For example: librdf_free_storage might nullify the storage by clearing its state, in some appropriate fashion, then nullify any iterator objects it (secretly) holds on to, then deallocate the storage object, but not the iterator objects. Nullification of an iterator (in this example) would discard any remaining objects, but not deallocate the iterator. It would be possible to hold onto and call a nullified object (because it hasn't been deallocated and remains valid), but it would always report 'no more objects', and therefore have no remaining dependence on the storage object. It may or may not be a high-level logical error to query a nullified object, but it should not be a library-level error. I confess I haven't looked at the code, but I suspect this would be a repetitive but fairly mechanical addition to the implementation. There would be no need to add the nullification functions to the exposed API. The addition would make it a lot easier to use librdf in contexts such as garbage-collected extensions where the user is otherwise released from worrying about this sort of release/reclamation ordering. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2010-04-03 18:21 normang New Issue ====================================================================== _______________________________________________ redland-dev mailing list [email protected] http://lists.librdf.org/mailman/listinfo/redland-dev
