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