[fusion] sequence io manipulators
When streaming unrelated fusion sets to unrelated ostringstreams from different threads, I get an invalid iterator error. This appears to be due to using a boost::fusion::detail::stream_data::attach's local static arena instance. static void attach(Stream& stream, T const& data) { static arena ar; // our arena ar.data.push_back(new T(data)); stream.pword(get_xalloc_index<Tag>()) = ar.data.back(); } I assume there are issues with using the unguarded stream_data::data std::vector<T*> from multiple threads. This implementation looks problematic in that the arena data does not get cleaned up until program exit as well. Jeff
On 3/26/13 3:12 AM, Jeff Flinn wrote:
When streaming unrelated fusion sets to unrelated ostringstreams from different threads, I get an invalid iterator error. This appears to be due to using a boost::fusion::detail::stream_data::attach's local static arena instance.
static void attach(Stream& stream, T const& data) { static arena ar; // our arena ar.data.push_back(new T(data)); stream.pword(get_xalloc_index<Tag>()) = ar.data.back(); }
I assume there are issues with using the unguarded stream_data::data std::vector<T*> from multiple threads. This implementation looks problematic in that the arena data does not get cleaned up until program exit as well.
Right. That code is quite old, IIRC inherited from Boost.Tuples. Would you care to provide a patch? Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On 3/25/2013 9:33 PM, Joel de Guzman wrote:
On 3/26/13 3:12 AM, Jeff Flinn wrote:
When streaming unrelated fusion sets to unrelated ostringstreams from different threads, I get an invalid iterator error. This appears to be due to using a boost::fusion::detail::stream_data::attach's local static arena instance.
static void attach(Stream& stream, T const& data) { static arena ar; // our arena ar.data.push_back(new T(data)); stream.pword(get_xalloc_index<Tag>()) = ar.data.back(); }
I assume there are issues with using the unguarded stream_data::data std::vector<T*> from multiple threads. This implementation looks problematic in that the arena data does not get cleaned up until program exit as well.
Right. That code is quite old, IIRC inherited from Boost.Tuples. Would you care to provide a patch?
Joel, See Ticket# 8336 with it's attached patch. I've compiled/linked/ran on VS2012 32bit and gcc4.2 32bit on Mac OSX 10.7. My app tests concurrent streaming. I have not added any such tests to fusion as I assume you do not want dependencies on thread library. I have not addressed possible issues with "static int index = std::ios::xalloc();" thread safety. gcc at least appears to guard this initialization with a mutex. I'm not sure what the standard guarantees in this regard pre/post C++11. Comments would be appreciated. Thanks, Jeff
AMDG On 03/26/2013 10:03 AM, Jeff Flinn wrote:
I have not addressed possible issues with "static int index = std::ios::xalloc();" thread safety. gcc at least appears to guard this initialization with a mutex. I'm not sure what the standard guarantees in this regard pre/post C++11. Comments would be appreciated.
C++11 guarantees that function statics are thread safe. C++03 doesn't. In Christ, Steven Watanabe
On 13-03-26 10:46 AM, Steven Watanabe wrote:
AMDG
On 03/26/2013 10:03 AM, Jeff Flinn wrote:
I have not addressed possible issues with "static int index = std::ios::xalloc();" thread safety. gcc at least appears to guard this initialization with a mutex. I'm not sure what the standard guarantees in this regard pre/post C++11. Comments would be appreciated.
C++11 guarantees that function statics are thread safe. C++03 doesn't.
Right. And IIRC, different versions of different compilers implemented that C++11 feature at different times, so it can't really be relied on in portable code. Yet. -- Eric Niebler Boost.org
On 26/03/13 21:01, Eric Niebler wrote:
On 13-03-26 10:46 AM, Steven Watanabe wrote:
AMDG
On 03/26/2013 10:03 AM, Jeff Flinn wrote:
I have not addressed possible issues with "static int index = std::ios::xalloc();" thread safety. gcc at least appears to guard this initialization with a mutex. I'm not sure what the standard guarantees in this regard pre/post C++11. Comments would be appreciated.
C++11 guarantees that function statics are thread safe. C++03 doesn't.
Right. And IIRC, different versions of different compilers implemented that C++11 feature at different times, so it can't really be relied on in portable code. Yet.
GCC has implemented it for a long time, since before it was standardized. MSVC still doesn't implement it.
On 3/26/2013 4:01 PM, Eric Niebler wrote:
On 13-03-26 10:46 AM, Steven Watanabe wrote:
AMDG
On 03/26/2013 10:03 AM, Jeff Flinn wrote:
I have not addressed possible issues with "static int index = std::ios::xalloc();" thread safety. gcc at least appears to guard this initialization with a mutex. I'm not sure what the standard guarantees in this regard pre/post C++11. Comments would be appreciated.
C++11 guarantees that function statics are thread safe. C++03 doesn't.
Right. And IIRC, different versions of different compilers implemented that C++11 feature at different times, so it can't really be relied on in portable code. Yet.
I checked and found fusion, tuple, locale libs all obtain an index from xalloc using local static initialization. chrono and units libs use class static member initialization. I'll prepare a patch to update fusion you use this latter initialization. Jeff
On 3/27/2013 9:03 AM, Jeff Flinn wrote:
On 3/26/2013 4:01 PM, Eric Niebler wrote:
On 13-03-26 10:46 AM, Steven Watanabe wrote:
AMDG
On 03/26/2013 10:03 AM, Jeff Flinn wrote:
I have not addressed possible issues with "static int index = std::ios::xalloc();" thread safety. gcc at least appears to guard this initialization with a mutex. I'm not sure what the standard guarantees in this regard pre/post C++11. Comments would be appreciated.
C++11 guarantees that function statics are thread safe. C++03 doesn't.
Right. And IIRC, different versions of different compilers implemented that C++11 feature at different times, so it can't really be relied on in portable code. Yet.
I checked and found fusion, tuple, locale libs all obtain an index from xalloc using local static initialization.
chrono and units libs use class static member initialization. I'll prepare a patch to update fusion you use this latter initialization.
I've updated the patch in Ticket# 8336 using Steven's static initialization approach from units io.hpp. Jeff
participants (5)
-
Eric Niebler -
Jeff Flinn -
Joel de Guzman -
Mathias Gaunard -
Steven Watanabe