Re: Coexistence of libxml++ and libxml2 in the same process

[Murray Cumming <murrayc murrayc com>]

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

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com