Re: [boost] [spirt] question regarding BOOST_SPIRIT_THREADSAFEandBOOST_SPIRIT_SINGLE_GRAMMAR_INSTANCE

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-28 13:32:51

Vladimir Prus wrote:
> 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
>>
>> a) be sure that loading/unloading of DLLS wasn't occurring while
>> in the midst of serialization stomething.
>
> Is this viable?

I believe it is

> Plugins are not necessary loaded at startup, they may
> be opened during normal work of a program,

I've presumed hat DLLS loaded at startup present no problems.

So the concern would be when a user invokes load_dll from different threads.

> and I don't know how an  application can reasonably check that some other 
> thread is in
> "midst of serialization something".

well, that would depend upon the application.

mult-threaded applications which don't explicitly use load/unload DLL should 
be able
to ignore this.  That covers a lot (most) of the cases.

The interesting case is where a user has used BOOST_CLASS_EXPORT and
has not explicitly instantiated his classes at compile time.  This is the 
case of
"plug-ins".

> Do you suggest that users employ a global mutex that will be help
> when either serializing anything - loading a DLL

In this case one will have to ensure that load_dll and serialization occur
sequentially.  Not a huge problem as one needs to load the dll before using
it anyway.  Also, one will have to ensure that dlls containing serialization
code are not loaded/unloaded while serializaiton is underway in another
thread.  One way for users to do this would be through a global mutex.
Whether this is the best or only way would be an issue that
the application would have to address.

The idea of including polymorphic serialization along with
class implementation code in a dynamically loaded DLL is a powerful
one that I wanted to support.  I believe I've accomplished this
in the serialization library with the recent improvements in
extended_type_info.  I've tested this functionality "by hand" with
windows and it seems to work as I would hoped.  I don't know
if anyone else will actually find it useful - but hope springs eternal.

Robert Ramey