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


   I still wonder if initializing the per thread variables from
the "global" values ain't the best approach, it allows to set up
the common environment for all threads a initialization time, and
if needed still allow to set up different per-threads defaults.


  This adds costs only at threads creation, and keeps the existing
code base except for one very limited point.

Can you elaborate a bit what additional costs you foresee?


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? 

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


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