On Wed, Jul 09, 2008 at 04:14:12AM -0400, Daniel Veillard wrote: > On Tue, Jul 08, 2008 at 09:57:09PM +0200, Roland Mainz wrote: > > Ok... but it seems this limits consumers in a way that they can't be > > nested or resources "moved" between threads (e.g. thread "a" creates a > > resource and then passes it completely over to thread "b" for further > > processing and disposal). > > I *really* don't understand what your problem is. > If you use recent parsing APIs, basically the parsing would *not* rely > on any global variable state (except maybe predefined entities values > but they should have a predefined value which is not thread specific !) > Make 100% sure you are using the recent parsing functions of libxml2 > those which don't rely on global variables for their processing. > Still I don't see how you would get data corruption. Maybe some of > your 'stuff' corrupts a parser or document dictionary. But I have > no idea.
Actually I have an idea. A very common failure pattern, one of your shared libraries is calling xmlCleanupParser() which resets the common global variables needed for libxml2 processing in the entire application. Find the instances of xmlCleanupParser() in libraries, remove them all, push the changes upstream. No library should ever call that function, if it does this will lead to serious random problems. Again, I'm shooting in the dark by lack of data, but this looks a very probable culprit. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
