[Top][All Lists]
[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?