Robert Ramey <ramey <at> rrsd.com> writes:

Is it possible that this might be related to the recently discovered fact (at least by me) versions of the serialization library are, contrary to intention, not thread safe? That is, conflict occurs when multiple threads are using serilization even with different archive instances due to the fact that they share the same gobal extended_type_info table. This has been addressed - and hopefully remedied in 1.35.

Robert Ramey

What does it mean that the serialization library is "not thread safe"? Does it mean that the serialization must be used in one thread only or the serialization can be used in different, non-concurrent threads? I'm not familiar with the serialization library internals so it's hard to me to make a guess where it is related to my case. My application is an RPC server that supports only one client connection. The client establishes connection, makes some calls to the server and exits. Each call can generate "events" that are stored on the server in a vector. After a call the client may call the server's function SerializeEvents which serializes the vector into buffer and transmits the buffer to the client. Actual serialization code is straightforward. void CEventLogger::Serialize(std::vector<BYTE>* pBuffer) { std::stringstream stream; boost::archive::text_oarchive ar(stream); ar & m_Events; std::string str(stream.rdbuf()->str()); if(str.length()) { BYTE *pBuf = reinterpret_cast<BYTE*>(const_cast<char*>(str.c_str())); pBuffer->assign(pBuf, pBuf + str.length()); } else pBuffer->clear(); } The client communicates with the server in one thread only. So the functions that are populating m_Events and CEventLogger::Serialize are called in different threads, but these calls are serialized. What you think? Can "not thread safety" be a reason in my case? Thanks, Sergey (Sorry, I forget to mention I'm using boost 1.33.0.)