lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Chicares
Subject: Re: [lmi] bad use of xml::init in LMI sources
Date: Thu, 27 Nov 2008 00:51:37 +0000
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

On 2008-11-26 18:56Z, Vaclav Slavik wrote:
[...]
>         The xml::init class is used to initialize the XML parser. For
>         thread safety it should be instantiated one time in the main
>         thread before any other threads use xmlwrapp. Non-threaded
>         programs should instantiate a xml::init class before using
>         xmlwrapp as well, at least for consistency.
> 
> But LMI doesn't use it like that
[...snip problems...]
> The simplest fix would be to simply not use xml::init at all, because
> LMI doesn't use threads and so doesn't need it.

Okay, so it's not really crucial. Still, we should fix it.

> Another would be, of course, to use xml::init as intended, by creating
> an instance in main(). But I understand why you wouldn't want to do
> that. In fact, this problem is more general: it makes it impractical to
> use xmlwrapp internally in any library [that doesn't expose its use of
> xmlwrapp in its public API].

Yet we could initialize it in main(). That's what we do for the boost
filesystem library's name-check policy, IIRC.

> So I'm thinking that a better fix would be to make it possible to create
> multiple instances of xml::init, as long as they are all created before
> any threads are launched. We could than safely create a global xml::init
> object in xml_lmi.cpp to initialize xmlwrapp at app startup (and
> similarly for xslt::init -- the latter derives from xml::init and so
> we'd have two xml::init instances in practice). Can you see any problem
> with doing that, or even a better solution?
> 
> The obvious problem is that it triggers libxml2 initialization very
> early, before main() starts. This means slower startup, but I think that
> after the product files are converted into XML format, LMI will get to
> loading an XML file soon after starting anyway...

I don't suppose it affects startup time materially, but it wouldn't
hurt to measure it.

Other random ideas:
 - a simple Meyers singleton that initializes itself only at first use?
 - a "nifty counter" as was used in the C++ standard library for cout?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]