Hi,
I've made a start on 0.4 development, in a new DEV_0_4 branch in CVS. I've
started out by trying to address the memory handling problems centered
around XML::Node, which is used pretty much throughout the library, and so
far the tests, and my own experiments, suggest a promising start.
The main effect of the changes so far is:
* Totally reworked node allocation and wrapping, we still don't copy
nodes
unless required, but we now track how many ruby_xml_nodes wrap a given
xmlNode. This is currently done using _private data - I know someone
asked
about exposing that member for app use but I can't see where else to
store
the data needed by the binding. Also, this will break compatibility
with
libxsl-ruby 0.3.x, but that's to be expected anyway - once this
branch
is
moving a bit more I'll introduce a parallel branch into libxsl-ruby.
* Changed the way nodes are handled WRT. their documents and parent
nodes,
to better fit with libxml2's memory model for the tree. We leave
memory
management with the library as much as possible, only stepping in
where
we
need to. This should fix up myriad problems that occur when copying
nodes
between documents and adding new nodes. It's slightly less efficient
now,
but once it's more stable we can probably streamline things a bit.
* Thread safety: After going through the code and making the changes
I've
made,
I'm now a lot happier that the binding is thread safe - as long as
libxml2
is compiled using the --with-threads option. Note though that this
doesn't
apply to custom parser error handlers - it's up to you to be
thread-safe
there. Later on I'd like to devise some specific tests for threadsafe
use.
* Error handler procs - won't get GC'd while you're not looking any
more (oops :->). This was causing a seemingly-random segfault.
I need people to look over the changes, try the new stuff out, play with
it, and generally try to break it - let me know if it works/doesn't work,
could be done better, or whatever. I'm hoping to really attack the bugs we
know about, and root out those we don't, but I won't be able to do it
without feedback as the work progresses...
Cheers,
--
Ross Bamford - [EMAIL PROTECTED]
_______________________________________________
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
