- Boost - lists.boost.org

[threadpool] new version with fork/join semantics (context swaps)
by k-oli＠gmx.de 19 Oct '08

19 Oct '08

Hi, I've uploaded a new version of threadpool (v8). It supports fibers (context swapping). Recursiv algorithms will now not block (see example below) -> you could recursivly calculate fibonacci number with one thread. I could verify that fiber-support works on Win XP Prof. (virtualized on Linux) with msvc 9.0 and OpenSolaris/Nexenta (also virtualized) with gcc-4.0. I get segmentation fault if I run the code on Linux (kernel 2.6.26) with gcc-4.3: #0 0x000000000041009b in boost::_bi::list1<boost::_bi::value<boost::tp::detail::pool_with_fibers<boost::tp::unbounded_channel<boost::tp::fifo> >::worker::wimpl::fiber_wrapper*> >::operator()<boost::_mfi::mf0<void, boost::tp::detail::pool_with_fibers<boost::tp::unbounded_channel<boost::tp::fifo> >::worker::wimpl::fiber_wrapper>, boost::_bi::list0> (this=0xffffffffd4000c28, f=@0xffffffffd4000c18, a=@0x7f81d400535f) at /opt/boost/include/boost-1_36/boost/bind.hpp:232 #1 0x00000000004100f4 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, boost::tp::detail::pool_with_fibers<boost::tp::unbounded_channel<boost::tp::fifo> >::worker::wimpl::fiber_wrapper>, boost::_bi::list1<boost::_bi::value<boost::tp::detail::pool_with_fibers<boost::tp::unbounded_channel<boost::tp::fifo> >::worker::wimpl::fiber_wrapper*> > >::operator() (this=0xffffffffd4000c18) at /opt/boost/include/boost-1_36/boost/bind/bind_template.hpp:20 #2 0x0000000000416c34 in boost::tp::detail::wrapp_functor<boost::tp::detail::fiber_impl_wrapper<boost::_bi::bind_t<void, boost::_mfi::mf0<void, boost::tp::detail::pool_with_fibers<boost::tp::unbounded_channel<boost::tp::fifo> >::worker::wimpl::fiber_wrapper>, boost::_bi::list1<boost::_bi::value<boost::tp::detail::pool_with_fibers<boost::tp::unbounded_channel<boost::tp::fifo> >::worker::wimpl::fiber_wrapper*> > > > > ( vp=0xffffffffd4000c10) at /home/graemer/Projekte/thread_pool/src/boost/tp/detail/fiber_impl_posix.hpp:29 #3 0x00007f81da2cd7e0 in ?? () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () I hope you can help me to fix this error (maybe it's raised by a design bug). regards, Oliver example: #include <iostream> #include <cstdlib> #include <stdexcept> #include <vector> #include <boost/bind.hpp> #include <boost/date_time/posix_time/posix_time.hpp> #include <boost/interprocess/detail/atomic.hpp> #include <boost/future/future.hpp> #include <boost/ref.hpp> #include "boost/tp/fifo.hpp" #include "boost/tp/pool.hpp" #include "boost/tp/poolsize.hpp" #include "boost/tp/support.hpp" #include "boost/tp/stacksize.hpp" #include "boost/tp/unbounded_channel.hpp" namespace pt = boost::posix_time; namespace tp = boost::tp; typedef tp::pool< tp::unbounded_channel< tp::fifo >, tp::with_fibers > pool_type; class fib { private: pool_type & pool_; int offset_; volatile boost::uint32_t & i_; int seq_( int n) { if ( n <= 1) return n; else return seq_( n - 2) + seq_( n - 1); } int par_( int n) { if ( n <= offset_) return seq_( n); else { tp::task< int > t1( pool_.submit( boost::bind( & fib::par_, boost::ref( * this), n - 1) ) ); tp::task< int > t2( pool_.submit( boost::bind( & fib::par_, boost::ref( * this), n - 2) ) ); return t1.get() + t2.get(); // dos not block if task is not ready } } public: fib( pool_type & pool, int offset, volatile boost::uint32_t & i) : pool_( pool), offset_( offset), i_( i) {} int execute( int n) { boost::interprocess::detail::atomic_inc32( & i_); int result( par_( n) ); printf("%d: fibonacci of %d == %d\n", i_, n, result); return result; } }; int main( int argc, char *argv[]) { try { pool_type pool( tp::poolsize( 2) ); boost::uint32_t i( 0); fib f( pool, 1, i); for( int i = 0; i<100;++i) { tp::task< int > t1( pool.submit( boost::bind( & fib::execute, boost::ref( f), 3) ) ); } pool.shutdown(); } catch ( boost::thread_interrupted const& ) { std::cerr << "thread_interrupted: thread was interrupted" << std::endl; } catch ( std::exception const& e) { std::cerr << "exception: " << e.what() << std::endl; } catch ( ... ) { std::cerr << "unhandled" << std::endl; } return EXIT_SUCCESS; }

1 0

Re: [boost] thread build on solaris
by Edward Peschko 19 Oct '08

19 Oct '08

H.J - hmm. That worked (thanks) but exactly why did it work? Shouldn't gcc be smart enough to realize that it is working either with a c++ file or linking to a c++ library? Ed It's part of a configure test as part of On Fri, Oct 17, 2008 at 9:24 PM, H.J. Lu <hjl.tools(a)gmail.com> wrote: > On Sat, Oct 18, 2008 at 11:13 AM, Edward Peschko <horos11(a)gmail.com> wrote: >> All, >> >> I'm trying to compile a thread with the boost, threading libraries, >> and am getting errors like these. >> >> gcc -o conftest -g -O2 >> -I/GAAL/pesced_release/install/fuego/include/boost-1_36 >> -L/GAAL/pesced_release/install/fuego/lib /tmp/aa.c >> -lboost_thread-gcc43-mt >> >> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: >> undefined reference to `__cxa_allocate_exception(a)CXXABI_1.3' >> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: >> undefined reference to `std::basic_string<char, >> std::char_traits<char>, std::allocator<char> >>>::_Rep::_M_destroy(std::allocator<char> const&)(a)GLIBCXX_3.4' >> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: >> undefined reference to `std::bad_alloc::~bad_alloc()@GLIBCXX_3.4' >> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: >> undefined reference to `__cxa_throw(a)CXXABI_1.3' >> >> This is on solaris 2.10, using gnu ld (version 2.18..) >> >> Any ideas on how to get around this? >> > > Please use g++ instead of gcc. > > > -- > H.J. >

2 1

Const-overload for bimap associative_container_adaptor::count()
by Matthew L. Creech 19 Oct '08

19 Oct '08

Would it be possible to include a const-overloaded version of count() for associative containers in boost::bimaps? I had some code like this: void CMyClass::func(size_t key) const { size_t num_elements=_member_map.count(key); ... } where _member_map was a std::map, and it worked fine. When I changed _member_map to a bimap, the equivalent code: void CMyClass::func(size_t key) const { size_t num_elements=_member_map.left.count(key); ... } gives an error, because count() is non-const (whereas GCC's std::map::count() is const). That's presumably done because the STL documentation declares count() as non-const (not sure why), but it doesn't seem there would be any harm in adding a const-overload so that this kind of code would compile when the underlying type supports it. The attached patch fixes the problem for me. Thanks -- Matthew L. Creech

1 0

[thread_safe_signals][signals2] review Nov 1st - Nov 10th
by Stjepan Rajko 19 Oct '08

19 Oct '08

Just a brief note: Thanks to the 5 reviewers that have signed up to review the Signals2 library (formerly known as thread_safe_signals) submitted by Frank Mori Hess, the review will happen as planned: November 1st - November 10th. Many thanks to the committed reviewers, and I hope other interested boosters that find some free time during the review period will be joining us as well. Kind regards, Stjepan

1 0

boost::asio::streambuf problem
by rod haxton 18 Oct '08

18 Oct '08

Hello, "Long time listener, first time caller..." I'm struggling with the "boost::asio::streambuf," and the "boost::asio::async_read_until." I'm trying to wait on the async_read_until, which I can do after the first message is sent, but subsequent messages received cause the streambuf to continuously grow. I am trying to use the streambuf via the .data() member. void TAsioSession::Start() { boost::asio::async_read_until(m_Socket, m_szAsioData, boost::regex("\n"), boost::bind(&TAsioSession::HandleRead, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } void TAsioSession::HandleRead(const boost::system::error_code& error, size_t bytes_transferred) { if(!error) { boost::asio::streambuf::const_buffers_type bufs = m_szAsioData.data(); std::string szBuffer( boost::asio::buffers_begin(bufs), boost::asio::buffers_begin(bufs) + bytes_transferred); LP_ICPACKET lpICPacket = reinterpret_cast<LP_ICPACKET>(const_cast<char*>(szBuffer.c_str())); // reset streambuf for reading (how?) . . . Start(); } Once I grab the data that is in the buffer, I want to reset the streambuf and go back to "async_read_until," and wait for another message to come in. I try to do the following to reset the streambuf pointers... // set the current put/get ptrs of streambuf to beginning of stream m_szAsioData.commit(-m_szAsioData.size()); m_szAsioData.consume(-m_szAsioData.size()); // clear the streambuff char szClear[512]; ZeroMemory(szClear, 512); m_szAsioData.sputn(szClear, sizeof(szClear)); m_szAsioData.sgetn(szClear, sizeof(szClear)); // set the current ptrs of streambuf back to beginning m_szAsioData.commit(-m_szAsioData.size()); m_szAsioData.consume(-m_szAsioData.size()); but the new message isn't at the head of the buffer, it is coming in at position 512 of the streambuf, and the streambuf grows. Any help would be appreciated. Thanks, Rod

1 1

[serialization] non-windows platform broken
by Juergen Hunold 18 Oct '08

18 Oct '08

Hi ! It seems that http://svn.boost.org/trac/boost/changeset/49349 Log: updated spirit headers to use "classic" broke the serialization build for all non-msvc and non-borland builds (all unices in fact ;-))) See http://www.boost.org/development/tests/trunk/developer/serialization.html for the yellow and red markers. And see http://tinyurl.com/5ltbd6 for details. The reason seem to be workaround macros like // spirit stuff #if (defined __BORLANDC__) && (__BORLANDC__ < 0x593) \ || (defined _MSC_VER) && #if (_MSC_VER <= 1300) #else #include <boost/spirit/home/classic/utility/chset.hpp> #endif found in boost/archive/impl/basic_xml_grammar.hpp where the #else clause contains non-existent headers. I've tried to fix this, but got lost in the vast amount of old, new and phoenix variants of spirit ;-(( Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[repost] outdated status\expected_results.xml
by JOAQUIN M. LOPEZ MUÑOZ 18 Oct '08

18 Oct '08

Hello, I first posted this some days ago, allow me to repost just in case it went unnoticed: This file has not been updated since 08/12/07: http://svn.boost.org/trac/boost/browser/trunk/status/expected_results.xml which suggests it contains the expected results for Boost 1.34.1. So, Boost 1.36 tests are and 1.37 tests will be comparing against an outdated file (each version should compare against the former). There doesn't seem to be any documentation on Boost about how to do the updating, and the file is not even mentioned at the release manager's checklist at http://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] New library in Vault: Msm (Meta State Machine)
by Christophe Henry 18 Oct '08

18 Oct '08

Hi Andreas, First of all, thank you for taking the time for such a lengthy answer. > So IIUC then you think that transitions crossing state boundaries are bad > practice and should be avoided at all costs? Yes I do (not at any cost of course). Not only because it looks to me like a goto, but also because I feel it is a breach of encapsulation, for example, in the diagram, the "alarm-beeps" state is showing its implementation. It is also unclear to me if the entry method of "alarm-beeps" will be called. > OTOH, the transition triggered by x can only be > made non-state-boundary-crossing by introducing a guard, which is IMO less > concise than allowing for the transition as shown in the chart. This is a matter of taste. I personally prefer this as it reduces the coupling of the system. > As an aside, I don't see much of a connection of state-boundary crossing > transitions with goto. Given your code in the C() function, any transition > could/would be implemented with goto? What I mean is that if you imagined a transition processing as a function call, code using entry pseudo-states would in effect look like the code in the C() function where you could skip the initialization work done in the entry of C and B. It was not meant as real code but as illustration. Sorry if I didn't manage to make my point clear. > Given the examples in the Harel paper and the fact that the UML standard > expressly allows them, I would encourage you to support them. So does C++ support goto and breaching encapsulation, and it still doesn't make them desirable to me. Now, I thankfully take the feedback, and if confirmed, I will add the entry/exit states. > for the same reasons I don't detect value in seeing a composite state as a fully > fledged state machine (as your framework seems to do). I know that the UML > has so-called submachines but they are really just simple composite states > with entry and exit points thrown in. I admit the UML standard is not too clear in its description of submachines but states the goal clearly (UML Superstructure specification v2.1.2 p549), as: "Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse". And this is a main design point for Msm. Submachines in Msm intend to be reusable blocks, like classes and functions. They have entry points (entry conditions and initial states), can be defined in different files and reused in different state machines. What defines a FSM with Msm is its transition table, not the inside of submachines. Submachines can be reused in different main state machines and the link between all is the transition table. Now, if the outside world knows the inside of the submachine, which would in turn know about the outside world, I'm afraid it'll be hard for submachines to be reused. However, your example and your point of view are very interesting as they force me to offer a better solution than the one I have (which would be in the init state to forward the events manually). Would the following compromise solution be acceptable to you? Like with deferred events, it would be possible to define automatic forwarding in a state (like the initial one) like this: typedef mpl::vector<T,T1,T2> forward_events; and at the end of the transition, these events would be resent (to the corresponding beep state as defined in the transition table). Like this, it is guaranteed that the entry methods are called, thus ensuring safe initialization and we would come close to an entry pseudostate. To explain better, I uploaded an image into the Vault. Regards and thank you for your time! Christophe

3 2

[1.37] [dynamic_bitset] Permission to port to the release branch
by Gennaro Prota 18 Oct '08

18 Oct '08

The latest changes to dynamic_bitset are either documentation improvements (markup, contents, wording) or removals of workaround code for compilers on which no tests are run anymore. I'll wait for a trunk test cycle anyway, but I thought to ask with some anticipation for permission to port them to the release-ready branch. -- Genny

2 2

Newbie want to get involved in boost projects and prepare for 2009 GSoC
by 徐兴军 18 Oct '08

18 Oct '08

Hi,all: I am a graduate student, and good at algorithm. If I want to get involved in boost projects and prepare for 2009 GSoC, which specific projects are suitable for me ? And how can I get started ? Thank you !

1 0