[redland-dev] [Redland RDF API 0000365]: Reduce/remove undocumented coupling between librdf objects (helps bindings to GC languages)

[Mantis Bug Tracker]

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                                    
======================================================================