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

[Murray Cumming <murrayc murrayc com>]

On Thu, 2010-11-04 at 17:12 +0100, Alessandro Pignotti wrote:
> 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.

Is anything else in libxml thread safe anyway?

> 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)

I don't understand what you are suggesting in these previous two
sentences. Sorry.

> -) 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
> _______________________________________________
> libxmlplusplus-list mailing list
> libxmlplusplus-list gnome org
> http://mail.gnome.org/mailman/listinfo/libxmlplusplus-list

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