You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am contemplating using Cereal in a heavily threaded process, and the discussion in the docs about a couple of global tables being managed under mutexes seems a bit concerning.
After a bit of lightweight empirical experimentation though (i.e. hacking in some prints), it appears that these locks are never used after process initialization prior to main being called. Perhaps deferred loading of shared libraries (or DLLs on Windows) could modify the shared data structures? If that is the case though, why isn't the code reading these shared data StaticObjects also taking locks in order to guard against such modifications while archiving polymorphic and/or versioned data?
In practical use, if archive objects are each carefully kept to a single thread, when will the Cereal StaticObject locks be used after the startup initialization? And if locks are being taken, are there steps I can take that could obviate the need to define CEREAL_THREAD_SAFE at all? (e.g. no shared libraries or at least no archiving while loading/unloading them, no threading prior to main)
The text was updated successfully, but these errors were encountered:
I am contemplating using Cereal in a heavily threaded process, and the discussion in the docs about a couple of global tables being managed under mutexes seems a bit concerning.
After a bit of lightweight empirical experimentation though (i.e. hacking in some prints), it appears that these locks are never used after process initialization prior to main being called. Perhaps deferred loading of shared libraries (or DLLs on Windows) could modify the shared data structures? If that is the case though, why isn't the code reading these shared data StaticObjects also taking locks in order to guard against such modifications while archiving polymorphic and/or versioned data?
In practical use, if archive objects are each carefully kept to a single thread, when will the Cereal StaticObject locks be used after the startup initialization? And if locks are being taken, are there steps I can take that could obviate the need to define CEREAL_THREAD_SAFE at all? (e.g. no shared libraries or at least no archiving while loading/unloading them, no threading prior to main)
The text was updated successfully, but these errors were encountered: