Re: Coexistence of libxml++ and libxml2 in the same process
- From: Murray Cumming <murrayc murrayc com>
- To: Alessandro Pignotti <a pignotti sssup it>
- Cc: libxmlplusplus-list gnome org
- Subject: Re: Coexistence of libxml++ and libxml2 in the same process
- Date: Thu, 04 Nov 2010 15:46:43 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]