From: Kirit Sælensminde (kirit.saelensminde_at_[hidden])
Date: 2008-08-28 23:55:53
Sorry I'm late to this - been very slowly trying to catch up on my reading.
Robert Ramey wrote:
> David Abrahams wrote:
>> Suggestion: handle that by deferring the availability of the
>> registrations associated with that DLL until the user explicitly says
>> it's safe to add them. The idea is that every DLL adds things to its
>> local registry and in a MT application, that is only combined with the
>> global registry via an explicit call, when presumably the user knows
>> no threads are doing serialization.
> I have always presumed that loading of DLLS would be under the control
> of the user program so that he could take appropriate steps to
There are places where this sort of thing is not under the control of
the application, or the person writing the code using serialisation has
no control of.
In our code we expose functionality through COM in a number of DLLs so
the load order and timing of the DLLs is under control of the programs
that use our objects. They can end up loading a DLL at any time and as
our COM instances are used to implement web site functionality the
timing of when COM objects are required is under control of the users
visiting the sites.
We have a similar requirement for a static library of factories for
serialisation (in our case for O/RM, but the principle is the same) and
when I put all of this together it seemed that the only way to do it
reliably was to use a read/write mutex around accesses to the static
data. This way most of the reads can still happen in parallel with the
very occasional writes taking exclusive control of the structure.
> a) be sure that loading/unloading of DLLS wasn't occurring while
> in the midst of serialization stomething.
> b) loading/unloading DLLS occurred one at at time.
> It seems to me that this is enough to avoid problems.
> Am I missing something?
I think that the lower level libraries don't have the information to
tell this for sure -- your library users who are writing application
level code can make a decision based on this, but anybody writing a
library on top of yours still may not know enough to be able to control
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk