From: Sergey Skorniakov (s.skorniakov_at_[hidden])
Date: 2007-08-23 03:04:30
>I could be that I since serialization isn't currently threadsafe anyway, No
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk