On Thu, 2007-23-08 at 11:13 -0600, Charlie Savage wrote: > Ah - interesting. A hybrid approach is extremely difficult because it > means you have to keep track of the ruby to libxml object mapping. For > example, say you have some ruby code that create a libxml node. That > ruby object would then implement a free method that frees the libxml > node. But let's say you end up with a 2nd ruby object pointing to the > same libxml object (which is really easy to do) - now you have a problem.
The current implementation uses a reference counting scheme within the xmlNode elements returned from libxml. It seems to me that it *should* be possible for this to work. The problems that I have discovered stem from libxml freeing entire document trees while there are still ruby objects referencing the nodes. When those ruby objects are subsequently garbage-collected, the xmlNodes in those objects have already been freed and sadness ensues. But I think the current mechanism is so close to working that it does not warrant a complete rewrite. As far as I can see, all trees should simply be walked prior to calling XMLFree to check for nodes referenced from ruby. Any such nodes should be removed from the tree, as they will be freed later when their referencing objects are garbage-collected. This probably also applies to attributes but that hasn't bitten me yet. > For SWIG I implemented support for mapping between C pointers and Ruby > objects by using a Hash Table (ruby's built in one, st_table). That > allows you to enforce a one-to-one Ruby to C object mapping. Do we want > to do something like that here? The couple issues with it are: > > * You have to hook it into every single binding method (easy in SWIG > since its all auto-generated) > > * Ruby object ids get reused, so you have to clean out old objects from > the hash table as soon as they are freed. > > If you have such a mapping, then a hybrid approach becomes doable as > long as you know absolutely for sure when a Ruby object owns a libxml > object and when it doesn't. When it does, you assign a free method. > When it doesn't, you don't. > > If we go down this approach, it might be worth using SWIG. My only > problem with SWIG is that the SWIG mapping language is very complex, and > almost no one is going to understand it. If it weren't so close to working already I'd probably be keen to see such a proven approach used, even if it is tricky. As it is, I'd prefer to see reasonably simple bug-fixes applied. Not my choice though - I'm not one of the project developers so I'll butt out now :-) > Charlie __ Marc
signature.asc
Description: This is a digitally signed message part
_______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
