[xml] FW: Re: make libxml2 slightly more thread-friendly

["Vlad Gusev" <vladyslav gusyev gmail com>]

> -----Original Message-----

> From: Daniel Veillard [mailto:daniel veillard com]

> Sent: Thursday, April 26, 2007 6:38 PM

> To: Vlad Gusev

> Cc: daniel veillard com

> Subject: Re: make libxml2 slightly more thread-friendly

>

>

> Use the mailing-list, thanks. I do not discuss problems like this

> out of record and archives.

>

> Daniel

 

---

From: Vlad Gusev [mailto:vladyslav gusyev gmail com]
Sent: Thursday, April 26, 2007 6:11 PM
To: 'daniel veillard com'
Subject: Re: make libxml2 slightly more thread-friendly

Dear Daniel,

Honestly, I spent no time to check my problems with libxml2 in the bug list properly
and found the only close topic in http://mail.gnome.org/archives/xml/2007-February/msg00064.html.

Let me shortly explain the problem. Look, please, at the code sequence starting from xmlReadFile:

xmlReadFile 

    xmlCreateURLParserCtxt

        xmlNewParserCtxt

            xmlInitParserCtxt

                xmlDefaultSAXHandlerInit

    xmlDoRead
        xmlParseDocument
            xmlInitParser
                xmlInitThreads

                    InitializeCriticalSection(&cleanup_helpers_cs)

                xmlDefaultSAXHandlerInit

...etc...

 

Thus, there are two calls of xmlDefaultSAXHandlerInit causing in its turn:

 

xmlDefaultSAXHandlerInit

    __htmlDefaultSAXHandler

        xmlGetGlobalState

            EnterCriticalSection(&cleanup_helpers_cs)

 

under condition of not main thread. That is the first call of xmlDefaultSAXHandlerInit can access the critical section

with no initializing it while the second one is ok.

 

I followed the simple instruction for 2.6.27 Windows version and preserved the default values for cscript-ing configure.js

(compiler=msvc, threads=native) with no trying, sorry, to investigate how macros were set. My library build crashed

in multithreading environment until I made workaround threads=no.

 

Regards, Vlad