Robert Ramey wrote:
Calls to the library should be wrapped in there own locks. I would expect that the top level entry points to serialization would be few in number and that each of these would have its own locks. I see no need to include locks withing the serialization library itself.
I strongly disagree. This requires the client to know implementation details of the library. The library should at least guarantee basic thread safety, so that two threads can use two different archive objects at the same time, which currently is not necessarily the case.
I believe that this is the case. The only shared global objects are collections of extended_type_info objects and base/derived registrations (void_cast_primitives). These collections are built/modified only during pre-execution or during loading/unloading of DLLs which export types or void_cast_prmitives. So I believe your concern could be addressed by a code which inhibited loading/unloading of DLLS while any archives are open. I don't think this has to be part of the serialization library.
I think you're going contrary to the basic threading assumption in the C++. If I explicitly use the same object from two different threads, I must use locking myself. If, for all appearence, I don't use the same object in two threads, but there's some *internal* shared data structure, it should be protected *internally*. In this case, there's some internal serialization table that I know nothing about, so it should be protected by serialization library.
So I believe your concern could be addressed by a code which inhibited loading/unloading of DLLS while any archives are open. I don't think this has to be part of the serialization library.
To begin with, those internal structures are present even when no archives are open, arent't they? Besides, I don't understand how you can "inhibit loading of DLLS". Say, one thread has created an archive and does something with it. Some other thread tries to open DLL. What should happen? Should that other thread get "sorry, some archives are open" error? And what will it do? Wait until the other thread is done with archive? And what if the other thread uses archive to talk over network and will never close the achrive? And even if it will close archive, how will the other thread wait for that? There's no public method that tells that any archive is open. - Volodya