Date: 2005-08-17 03:16:39
Robert Ramey wrote:
> I'm still considering this. I'm a little bit concerned about what
> when there are multiple instances of extended_type_info for a specific
> in the global table.
When unregistering from the global type registry the type info address
should be used. But when comparing type info objects for equality, for
example when performing void casts, it shouldn't. I agree that it's not
the nicest solution and this should be given some more thought.
>> Finally, I'd like to bring your attention to the issue of thread
>> safety. Since Boost.Serialization has a number of global objects,
>> access to them should be safe-guarded by a synchronization primitive,
>> such as a mutex.
> This is something that should be left outside the serialization library.
> Calls to the library should be wrapped in there own locks. I would
> that the top level entry points to serialization would be few in number
> 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.
If we use dynamically loaded DLLs and use multiple threads to do so,
for example, we need to lock _every_ call we make to
Boost.Serialization. Given that some of these calls are hidden in
static global variables, i.e. behind the BOOST_CLASS_EXPORT macro, it
is not even possible for us to perform this locking at such a granular
How about making this an optional feature via a #define? Adding the
locks to the code is quite straightforward. I can provide you with a
patch, if desired.
Phone: +43 7229 78040-218
Fax: +43 7229 78040-209
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk