|
Boost : |
Subject: Re: [boost] [interprocess][trunk][windows] named_mutex doesn't work whithin a DLL
From: joaquin_at_[hidden]
Date: 2010-09-10 02:13:00
Ion Gaztañaga escribió:
> The lazy init does not work because somehow get() is being called in a
> static object (static_initializer()->init()), so it's lazily but *too
> early* instantiated.
>
This is aspect of Boost.Flyweight is by design, instantiation of the
singleton class is made
during the program dynamic initialization phase so as to avoid
concurrency problems
to a large extent (see http://tinyurl.com/38jknra ).
> If intermodule_singleton is used as a singleton outside static classes
> in dlls, then I guess there is no problem.
>
No solution for my problem :-(
> In the future I'll change intermodule_singleton to use
> windows_managed_shared_memory so that we can avoid any call to COM objects.
>
That'd be terrific. Do you have a roadmap for this?
> According to microsoft documentation, we shouldn't even call C runtime
> memory management functions in DllMain, which is really frightening.
I've always found this particular restriction a little hard to justify
(and really never saw
a crash attributable to this): in the doc you refere to it reads:
"The library loader. DLLs often have complex interdependencies that
implicitly define
the order in which they must be loaded. The library loader efficiently
analyzes these
dependencies, calculates the correct load order, and loads the DLLs in
that order."
and also
"You should never perform the following tasks from within DllMain:
[...] Use the
memory management function from the dynamic C Run-Time (CRT). If the CRT
DLL is not initialized, calls to these functions can cause the process
to crash."
Supposedly the library loader analysis should lead in every case to CRT
DLL (which
does not depend on any user-created DLL) being loaded *before* any
user-created
DLL, shouldn't it? Why then the caveat?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk