I could be that I since serialization isn't currently threadsafe anyway, No one builds with this switch and the issue doesn't come up.
Yes. But I had patched library to make it thread-safe and also define BOOST_SPIRIT_THREADSAFE to be on the safe side. And I'm wrong - BOOST_SPIRIT_THREADSAFE is not required here. It should be used only if grammar instance shared between threads.
I would have hoped that this would be automatically taken care of by the following sequence of conditions:
bjam <threading>multi => config/BOOST_HAS_THREADS =>inclusion of reference to threading library => link with threading library.
No, as it mentioned in documentation (http://www.boost.org/libs/spirit/doc/grammar.html#multithreading).
Also, I haven't looked at the threading library in enough depth to understand why the whole library can't be a header only library. After all, isn't is basically a wrapper around native OS primitives?
I think, the whole threading library can't header-only, at least under windows, because it should handle TSS cleanup, and the simplest and the safiest way to achieve it automatically is to process DLL_THREAD_ATTACH / DLL_THREAD_DETACH notifications into DllMain. However, I see no reasons why simple mutexes can't resides in headers completely.
Robert Ramey
Sergey Skorniakov wrote:
I'm not sure that BOOST_SPIRIT_THREADSAFE is really required in the case of serialization - I'm not very familiar with spirit. But when I build boost with the following user-config jam file:
using msvc : 8.0 : : <cxxflags>"-wd4996 -wd4103 -Zp4 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_SECURE_SCL=0 -DBOOST_SPIRIT_THREADSAFE -DBOOST_THREAD_USE_DLL " <linkflags>"-LIBPATH:%BOOSTROOT%/lib" ;
the resulting boost_serialization*.dll depends on boost_thread*.dll
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost