> -----Original Message----- > From: Daniel Veillard [ <mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED] > Sent: Thursday, April 26, 2007 6:38 PM > To: Vlad Gusev > Cc: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 6:11 PM To: '[EMAIL PROTECTED]' 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> 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
_______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
