Re: Re[2]: [lmi] bad use of xml::init in LMI sources

[Vaclav Slavik]

On Thu, 2008-11-27 at 01:59 +0100, Vadim Zeitlin wrote:
> I was a bit afraid to reply to original message as I thought I was missing
> something obvious because my first thought was to do exactly this, i.e. to
> initialize xml::init on demand. As long as LMI has a single thread only
> this is very simple to do and seems to solve the problem quite nicely.

Again, as long as we're talking about LMI-specific fix, then by far the
simplest fix is to not use xml::init at all. libxml2 already does
on-demand initialization, but it only works in single-threaded case.

The situation is different for xslt::init, which does some
initialization that libxslt doesn't perform on demand (namely, it
registers all EXSLT extensions). But we can ignore that in LMI too,
because LMI stylesheets don't use any extensions as far as I can tell
(at least the xslt_lmi.cpp code doesn't initialize extensions).

I'd prefer to fix this in xml::init itself -- that's where the
underlying problem is, in its design. Removing xml::init uses from LMI
or adding code to ensure that only one instance is created (in our code)
are merely workarounds. A (subjectively) better fix would be to have
more flexible thread-safe initialization mechanism in xmlwrapp, so that
we don't have to worry about it anymore, not even if we, for example,
start using some XSLT extensions in the future.

>  A potential problem I see with this is that it might be too late to
> destroy it at global objects destruction time.

I don't think that can be a problem. But then, I don't what what kind of
problems with this did you have in mind.

Regards,
Vaclav