[xml] Re: libxml2 thread problem

[Cc'ing the list, so that people can double check and share findings]

On Wed, Nov 20, 2002 at 04:20:18PM +0800, William M. Brack wrote:
Hi Daniel,

  I have been beating my brains out with the above, and finally
resulted to "brute force" debugging - tried replacing each changed
*.c module in ver 27 with the corresponding from ver 26.  Found it
is caused by parserInternals.c, and further isolated the problem
to be in xmlInitParserCtxt.  It seems to be caused by the changing
of the line

   initxmlDefaultSAXHandler(sax, xmlGetWarningsDefaultValue);

to become

   memcpy(sax, &xmlDefaultSAXHandler, sizeof(xmlSAXHandler));

  Well, stupid me, I can't see any reason why the change shouldn't
work (or, more precisely, why this should not be thread-safe).  I
will continue to think about it, but thought it might be helpful
to you to know this much.

  Thanks a lot Bill, that's precious informations !
I can understand it being not thread safe because the memcpy does not
take an exclusive lock before trying to access this global variable.
If another thread modifies it at the same time anything can happen.

On the other hand I made that change because changes made globally
to &xmlDefaultSAXHandler should be reflected in any new ParserCtxt created
and using initxmlDefaultSAXHandler() simply does a reset from the
predefined values. This was breaking XSLT to some extent.

I think the right way to fix it is to make sure one can copy the
current state of xmlDefaultSAXHandler for the new parser context without
risk in case of threaded operations. But that requires a bit of analysis
(and possibly of refactoring). 

   thanks a lot, I think this will save everybody involved a lot of time !!!


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]