Re: [xml] New libxml which is reentrant ?
- From: Daniel Veillard <veillard redhat com>
- To: Roland Mainz <roland mainz nrubsig org>
- Cc: libxml mailing list <xml gnome org>
- Subject: Re: [xml] New libxml which is reentrant ?
- Date: Wed, 9 Jul 2008 05:17:42 -0400
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
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
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.
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev