[xml] Re: libxml2 thread problem

[Daniel Veillard <veillard redhat com>]

[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

-- 
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/