I've delved a bit more into the issue and the handlers are completely non thread safe, being saved inside global data in the library address space. I think the only sane approach would be purgin away the specialized handlers and: -) Allocate C++ instances Just in time (checking for _private being NULL) -) Deallocate the instances by traversing the children of nodes before calling xmlFree* What do you think? Alessandro On Thursday 04 November 2010 15:46:43 you wrote: > On Thu, 2010-11-04 at 03:49 +0100, Alessandro Pignotti wrote: > > On Wednesday 03 November 2010 21:05:41 you wrote: > > > On Wed, 2010-11-03 at 18:43 +0100, Alessandro Pignotti wrote: > > > > I've a proposal, the code could be modified to call > > > > xmlRegisterNodeDefault before any xmlNew* call and to reset the > > > > handler to the default one after that. > > > > This approach would preserve the current interface while making > > > > libxml++ less intrusive. I'm working on a patch to implement this > > > > solution, any comment? > > > > > > I'd like to preserve any existing state, and a patch for that would be > > > welcome. > > > > > > However, doing that only at first use is a) harder to get right always > > > and b) might cause a slow down later rather than sooner, just at the > > > point where it's most annoying. So I'd like to consider that > > > separately. > > > > It's not enough to do the RegisterNode and DeregisterNode handlers setup > > at first use. They must be set up and reset each time a libxml2 call > > (that could create a new node) is used. > > I wonder if we can be sure when a new node will be created, though I > guess we'd soon find out. > > Do you know if this will have any performance impact? Is it just setting > a function pointer variable? If so, then I guess it's worth trying. > > However, I would still like this in two patches. First, preserving state > using the existing init() and then the rest. > > Note that I think the entire idea of these global libxml functions is > silly and I doubt whether we can ever completely work around them, > though it's worth a try. I would much prefer that they were per-context. > > > IMHO is not correct to override the handlers for > > > > the whole calling thread (where normal libxml2 might be in use), and even > > less overriding them for newly created threads. > > > > The approach I'm proposing involves setting and resetting the handlers > > each time as needed guaranteeing that, when leaving libxml++ code the > > state is the one as expected by the environment. I think the handlers > > are (or are accessed through) thread local variables so setting them is > > relatively fast. Anyway I really feel the current implementation is > > broken and not correctly encapsulated from the environment. > > > > Best regards, > > Alessandro Pignotti
Attachment:
signature.asc
Description: This is a digitally signed message part.