On May 28, 2008, at 10:55, Marc Munro wrote:

Well, it's not quite a null set.  I can write C, and I have some
knowledge of XML.  My problem is being able to spare the cycles.  I am
using libxml for my own free software project and I would rather spend
my free cycles on that than on the supporting infrastructure.

I may have to change my mind though, as I appear to be at the limits of
the current stability of libxml.  It looks like my choices are
contribute to libxml or rewrite what I have in another language (none of the other libraries for ruby are anything like fast enough). Right now I'm thinking that my project's long term future might be with a rewrite
in D.

However I am prepared to spend a little time looking at the issues in
libxml, and I have a question about the entire philosophy of the old
reference counting memory management implementation, and the new
mark-sweep based approach.

1) The reference-counting implementation allowed multiple ruby
references to the same C structures: is this also true of the newer
approach?

The new model does not allow this. A single C object has at most one ruby peer object. If by traversal through the xml, by xpath or otherwise, a node is returned that already has a ruby peer, the same ruby object will be returned. If there is no ruby peer, it is allocated.

2) Is there a fundamental need for more than one ruby object to
reference any libxml C object?

No need and many serious problems with having more than one-to-one associations.

3) I am not that familiar with the Ruby memory management model but
would the following rather different approach be feasible: when a ruby
objects is created the C object is given a reference to it, and when the
ruby object is garbage collected the corresponding C object loses its
reference and is then conditionally freed (if none of the associated
nodes have remaining references)?

That is how the new memory model works. The ruby peer has an internal void reference to the libxml object and the libxml object member _private holds either NULL when not peered or a VALUE to the peer. Ruby object free will reset _private to NULL and if the libxml node has no parents or enclosing document it calls free for libxml as well. If cleanup is initiated from the libxml side, all nodes as they are reclaimed, via ruby_xml_node_deregisterNode, will be checked and dereferenced on the ruby peer.


I am beginning to think, admittedly with little real evidence and a high likelihood of being wrong, that the fundamental stability problem arises
more because of the fact that we allow the C objects to be shared by
multiple ruby objects than anything else.

That was the single largest problem which should be resolved. The issues that remain are as yet undefined.


Comments, answers?

__
Marc

On Tue, 2008-05-27 at 11:43 -0400, Dan Janowski wrote:
The intersection is a null set. The best hope may be rubinius where
the extensions can be written in ruby. Fixing the memory model for
nodes and documents made a big difference, but the problems that are
lingering are elusive and compounded by ruby's obsficating GC. I put a
lot of time into it, but the maintenance is clearly more demanding
than I, or any one person, can provide. So here we are.

On 5/27/08, Sean Chittenden <[EMAIL PROTECTED]> wrote:
               I shifted out of libxml to the (much) slower REXML and
               an ad-hoc
               over-the-network Java based XSD validation system. I
               would love to get
               libxml-ruby working again. A lot of my projects will
               depend on it.

               Dan, how can other people help? Is there someone who
               can coordinate
               other people's efforts in the right direction?


       Sean's Posit #6: The group of people who need fast XML
       processing and the group of people know C are almost
       completely orthogonal technical groups.

       Ruby (or more specifically rails) has turned into a kind of
       open source refuge for .net developers who lack much clue, so
       the signal to noise ratio for most ruby projects is...
        atypical and out of line.

       What the project needs are people who can actually program in
       C, understand XML and are in a position to spend cycles on
       this problem.  As is, there aren't many who have these two
       essentially non-overlapping skills and rarer still, people who
       have cycles to spend on the thankless job of library
       development.  -sc

       --
       Sean Chittenden
       [EMAIL PROTECTED]


       _______________________________________________
       libxml-devel mailing list
       libxml-devel@rubyforge.org
       http://rubyforge.org/mailman/listinfo/libxml-devel


_______________________________________________
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
_______________________________________________
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel

_______________________________________________
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel

Reply via email to