On 28/01/2017 04:29, Simon Haegler wrote:
i am debugging an application where several shared libraries contain statically-linked copies of boost::thread (and other boost components). this means the static part of boost::thread is multiple times present in the process.
on macos (apple clang 7.3) we see rare (but reproducible) access violations caused by boost::thread_specific_ptr::get() unexpectedly returning nullptr. if we enable assertions we get an assert in thread.cpp:151
if we dynamically link boost the problems go away. i can superficially understand that linking only one "common" instanceof boost::thread is "more safe".
As Niall said, the general rules for library interaction are to not do that. You can sometimes get away with it if you're very careful about isolation -- in this case, it would probably work if you made sure that the thread_specific_ptrs are only ever accessed on threads that were started by the same library, and completely hid these threads from the consumers of the library -- but this way lies dragons, and it's far too easy to make seemingly simple changes that poke a hole in the isolation and break things, sometimes in subtle ways. So don't do it.