Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Understanding Cereal thread safety #721

Open
abrownsword opened this issue Oct 23, 2021 · 0 comments
Open

Understanding Cereal thread safety #721

abrownsword opened this issue Oct 23, 2021 · 0 comments

Comments

@abrownsword
Copy link

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant