Re: [boost] [spirt] question regarding BOOST_SPIRIT_THREADSAFE andBOOST_SPIRIT_SINGLE_GRAMMAR_INSTANCE

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 
this either.

Kirit