Re: [boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-18 00:54:07

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