great to hear ... checking the specific commit, it seems that the integration into the boost infrastructure (doc/testfarm etc) is still missing ... please compare with r79196, the specific commit for boost.lockfree.
thanks for the pointer, will fix it, and if you notice anything else, just write so I can fix it ASAP
i wonder, what is the current state of boost.atomic regarding interprocess communication?
if BOOST_ATOMIC_*_LOCK_FREE==2, then the corresponding data type is interprocess-safe
i see ... do you have any plans to provide a metafunction or traits class, which provides this information at the level of the c++ language so that it can be used for template metaprogramming?
(this behaviour is only recommended for std::atomic, but not guaranteed)
i know :( imo, this is not very helpful, though and boost should follow the recommendation of the standard ... but since compilers start to implement atomic<> these days, do you know the behavior of these implementations regarding shared memory?
as per the suggestion during review I have implemented a partially specialized template representing the *_LOCK_FREE macros to allow implementing an "interprocess_atomic" that is safe independent from the data type (as long as atomic_flag is safe, of course)
according to the latest draft that i have on my machine, atomic_flag shall be atomic. cheers, tim