Re: [xml] side effects of thread-enabling libxml2

On Fri, May 09, 2003 at 05:05:20PM +0200, Stéphane Bidoul wrote:

Daniel's suggestion to initialize the per-thread globals from
the values in the main thread would ensure unchanged behaviour
for a non-thread-aware client. But, as he said, that would require 
locking too if clients are allowed to change the globals 
when threads
are running. Also, it would slightly change the behaviour
(since the initial value of per thread globals would be different)
-- however I don't think that behaviour is explicitly documented.

  Yep, still IMHO it's the cleanest solution.

Okay. That solves the problem indeed, and does not look hard to do.
Shall I give it a try? 

   Well if you have time, yes . I think I suggested adding functions
to register the global default values and the other things needed would be
to take a lock when initializing a thread set of local variables.

And once that is done, I plan to experiment with thread-enabling
the python bindings (by releasing the global interpreter lock).

  Yes, that would allow to make easy regression tests, and actually
benefits from the parallelism for parsing different instances simultaneously
when using Python. I think there was some posts in the XML-Sig list about
how to avoid the global lock, I don't have the reference handy...


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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