As someone who has experienced a good number of these crashes, who has attempted to track them down, and who has at least some C experience, I would like to make a recommendation.
From my own reading and limited understanding of the code I don't think there is anything fundamentally wrong. At least not systemically: there may be specific interfaces that need more work but I think Dan's new memory model stuff is, on the whole, wonderful. There clearly have been problems. I haven't hit any since upgrading to the latest svn version about 2 weeks ago but I'm not yet feeling confident that we're there yet. The big problem from my point of view is that debugging is too damn difficult, and I think is a fault with ruby 1.8 rather than with libxml. If there is work to be prioritised right now, I would recommend making libxml and libxsl work with ruby 1.9. Ruby 1.9 is much friendlier to valgrind which is the ideal tool to use to find memory faults. I intend to run my app under ruby 1.9 as soon as I'm able, and I will happily run it using valgrind to help track down the remaining issues. Respectfully. __ Marc On Wed, 2008-03-05 at 07:19 -0800, Trans wrote: > Seeing that no one else has responded, I take as my cue to raise a red > flag. I haven't talked to Dan about this, but I'm going to go out on a > limb and say, that after following this project for many years now -- > not to mention personally working to revitalize it TWICE, I've come to > the conclusion that there may be something fundamentally wrong with > its design. For some reason there have always been segfaults, and no > one can seem to get rid of them all. Unfortunately, I'm not a C coder, > so I can't really assess this from a technical standpoint, but only as > as the "hands-off" project manger/assistant-manager role I've > maintained, and as a user. While the library works fine in many cases, > there seem to be enough problem cases that the library can't pick up > general traction. Perhaps others can fill in on the technical > difficulties and the breadth of these issues. > > While problems could be arising from libXML2 itself I suspect that it > is not generally the case, which makes me wonder how libxml-ruby is > actually designed under the hood. Wouldn't it makes sense simply to > map the libxml2 api to the Ruby C extension essentially one for one, > and then write everything else as a pure-Ruby "Ruby-way" wrapper > around that? Maybe this is how it is designed, but I can't really > imagine it because I would expect it to work fairly flawlessly if that > were the case. But like I said I'm not a C coder, so I can say for > sure. I just wanted to put my thought out there and get some feed back > on this. > > So I think at this point, the questions must be asked: How serious are > these continuing issues? Are they fixable? And should the current code > be abandoned and this project completely re-written from the ground up > instead? -- Or am I interpreting the error reports and the otherwise > relative silence on this list incorrectly? > > T. > _______________________________________________ > libxml-devel mailing list > libxml-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/libxml-devel >
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
