- Boost - lists.boost.org

[boost.thread] how to delete this thread from within the thread and thread hangs
by Tan, Tom (Shanghai) 19 Aug '09

19 Aug '09

I am using boost::thread_group to create(using thread_group::create_thread()) and dispatch threads. In order to limit the max thread numbers, at the end of each thread, I remove the thread from the thread_group and delete the thread itself(so that I could decide whether new threads need to be created). However it hangs somewhere between the creation and deletion of the last thread (say the 999th one of 999 in total). My questions are: -1) is it OK to delete the thread from within itself like what I do? if not, what the best way to achieve this -2) why does my code hangs? Below are the related code: //1- code to create and dispatch thread { //mutex for map<thread_id, thread*> operations boost::mutex::scoped_lock lk(m_mutex_for_ptr); // create a thread for this->f(duplicate_hashes) boost::thread* p = m_thread_group.create_thread(boost::bind( &detectiveT<equal_predicate>::f, this, duplicate_hashes )); // save the thread_id -> thread pointer map for later lookup and deletion m_thread_ptrs.insert(make_pair(p->get_id(), p)); // log to console for debug cout << "thread created: " << p->get_id() << ", " << m_thread_group.size() << ", " m_thread_ptrs.size() << "\n"; } //2- code of the thread execution void f(list<map_iterator_type>& l) { Do_something(l); boost::this_thread::at_thread_exit(boost::bind( &detectiveT<equal_predicate>::remove_this_thread, this )); } //3- code to delete the thread itself void remove_this_thread() { { //mutex for map<thread_id, thread*> operations boost::mutex::scoped_lock lk(m_mutex_for_ptr); boost::thread::id this_id(boost::this_thread::get_id()); map<boost::thread::id, boost::thread*>::iterator itr; itr = (m_thread_ptrs.find(this_id)); if(m_thread_ptrs.end() != itr) { // remove it from the control of thread_group m_thread_group.remove_thread(me); // delete it delete itr->second; // remove from the map m_thread_ptrs.erase(this_id); // log to console for debug cout << "thread erased: " << this_id << ", " << m_thread_group.size() << ", " << m_thread_ptrs.size() << "\n"; } } } Thanks.

1 0

Introduction
by Jeff 18 Aug '09

18 Aug '09

Hey everyone. I'm Jeff Gosling and been deving in C++ for 8+ years now and I'm looking to get involved in an open source community I am very interested in getting involved in Boost development. I've subscribed to the developer mailing list and have browsed through the community webpage. I've also read up on all the existing boost modules/projects. Obviously I have a bit more reading to do to get to grips with Boost. What I was wondering is how specifically can I help? Where is a good place for someone new to Boost to start? Is there a task list that I can look to for something new to do? Thanks, Jeff

2 1

[1.40.0] Beta 1 release candidate available
by Beman Dawes 18 Aug '09

18 Aug '09

1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/ Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. Thanks, --Beman

12 29

boost build output locations
by Zachary Turner 18 Aug '09

18 Aug '09

I notice there's some strange asymmetries in the locations that the standard boost build process outputs binaries to. Is there a reason for this? For example, running bjam variant=debug,release address-model=32 I get the following directory structure: bin.v2 --libs ----date_time\build\msvc-9.0 ------debug --------address-model-32 ---------- boost_date_time-vc90-gd-1_39.dll ---------- boost_date_time-vc90-gd-1_39.lib ----------link-static ------------threading-multi -------------- libboost_date_time-vc90-mt-gd-1_39 Alright there is one asymmetry evident. The dll version of the binaries are in address-model-32, and the static library version of the binaries are in address-model-32/link-static/threading-multi. Should there be like a link-dynamic and a link-static? It makes it much easier to automate linking and building if everything is symmetric, because in some compilers (e.g. visual studio) you don't have as much control as you do with a makefile. So then we take a look at boost::thread bin.v2 --libs ----date_time\build\msvc-9.0 ------debug --------address-model-32 ----------link-static ------------threading-multi -------------- libboost_thread-vc90-mt-gd-1_39.lib ----------threading-multi ------------ boost_thread-vc90-mt-gd-1_39.lib ------------ boost_thread-vc90-mt-gd-1_39.dll This time, the dll versions appeared under address-model-32/threading-multi instead of just address-model-32 like in date_time. Am I going crazy and I have a messed up system, or is this just the way it is? Is it easy to change, or would it be undesirable to change for some reason? Zach

2 1

[move][container] Fast-track reviews for Move and Container?
by Ion Gaztañaga 17 Aug '09

17 Aug '09

Hi, As some others have mentioned, I'd like to ask if Boost.Move and Boost.Container could meet the requirements for a Fast Track review (the Review Wizard has the last word according to the Boost Formal Process, but I'll like to see if there is consensus). Arguments: Boost.Move -> Only one header (move.hpp) -> Technique already in use in Boost (in several detail namespaces). This is a proposal for a common implementation. -> Boost-conformant implementation available in sandbox. Boost.Container -> Most of them standard containers -> Node containers are just wrappers over Boost.Intrusive -> Most containers (all except stable_vector) were already reviewed for Boost.Interprocess. -> Boost-conformant implementation available in sandbox. I'll be specially interested in pushing Move first, so that we could have move semantics for Boost 1.41. Best, Ion

4 6

Re: [boost] [1.40.0] Unmerged changes delaying beta 1
by Ralf W. Grosse-Kunstleve 17 Aug '09

17 Aug '09

> I'd prefer these changes go in 1.40.0 if possible. Since they have > been stable on trunk, and we are waiting a few more days anyhow for > beta feedback, I don't see a lot of risk. So please merge, and then > watch the release tests to make sure nothing breaks. All {boost,libs}/python changes are now merged into the release branch. Thanks to Steven Watanabe and Henrik Sundberg for pointing out the http vs. https problem. Ralf

1 0

Re: [boost] [1.40.0] need svn merge advice (was: Unmerged changes delaying beta 1)
by Ralf W. Grosse-Kunstleve 17 Aug '09

17 Aug '09

Beman gave me the advice below. When trying to svn merge libs/python I'm running into this error: svn: Access scheme mixtures not yet supported ('http://svn.boost.org/svn/boost/trunk/libs/python/test/enable_shared_from_th…' and 'https://svn.boost.org/svn/boost/branches/release/libs/python/test') svn: Error reading spooled REPORT request response The full output is below. Fedora release 11 (Leonidas) % svn --version svn, version 1.6.4 (r38063) compiled Aug 7 2009, 03:42:39 The working copy was checked out fresh with this client. The merge command is OK for boost/python. Adding --force doesn't help for libs/python. Last night I locally tested after simply copying the boost/python and libs/python directories into a working copy of the release branch. That works fine, but there will be no merge info if I commit from the manually modified working copy. IIUC that will be a problem for future merges. What's the best way forward? What if I commit from the release working copy with the manual copies from the trunk, then manually edit svn:mergeinfo to tell it I have everything from trunk up to this point? -- Secondary question: should I do this at the top level (branches/release) or in the subdirectories (branches/release/boost/python, branches/release/libs/python)? Any advice is appreciated; I'm quite afraid of doing something bad to the merge info. (The svn documentation explicitly tells me not to merge in subdirectories in order to avoid pitfalls...) Ralf ----- Original Message ---- From: Beman Dawes <bdawes(a)acm.org> To: Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> Sent: Monday, August 17, 2009 9:12:37 AM Subject: Re: [boost] [1.40.0] Unmerged changes delaying beta 1 I'd prefer these changes go in 1.40.0 if possible. Since they have been stable on trunk, and we are waiting a few more days anyhow for beta feedback, I don't see a lot of risk. So please merge, and then watch the release tests to make sure nothing breaks. > (I don't have any experience working with the release branch...) The merge process is pretty simple. Assume you have a working copy of branches release at \boost\release: svn merge http://svn.boost.org/svn/boost/branches/release/boost/python \ http://svn.boost.org/svn/boost/trunk/boost/python \ \boost\release\boost\python svn merge http://svn.boost.org/svn/boost/branches/release/libs/python \ http://svn.boost.org/svn/boost/trunk/libs/python \ \boost\release\libs\python % svn merge --force http://svn.boost.org/svn/boost/branches/release/libs/python http://svn.boost.org/svn/boost/trunk/libs/python /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python --- Merging differences between repository URLs into '/net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python': U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/andreas_beyer.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/stl_iterator.py U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/exec.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/slice.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/object.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/enum.py svn: Access scheme mixtures not yet supported ('http://svn.boost.org/svn/boost/trunk/libs/python/test/enable_shared_from_th…' and 'https://svn.boost.org/svn/boost/branches/release/libs/python/test') svn: Error reading spooled REPORT request response

3 2

[C++0x] Report from Frankfurt committee meeting
by Beman Dawes 17 Aug '09

17 Aug '09

The C++ standards committee met in Frankfurt, Germany, last week. Key actions: * Concepts have been removed from C++0x. The committee is very much in favor of Concepts. But Concepts are seen as so important that they have to be right. And the strong consensus was that getting Concepts right, for any reasonable definition of "right", would add several years to the schedule. There was also a consensus that an implementation of a compiler that could compile the entire standard library is part of the definition of "right". While ConceptGCC has been a great help, it isn't there as far as validating "right". Personally, I think Clang may end up being the compiler that eventually validates Concepts. * The range-based for loop and some other library features that were dependent on Concepts will be retained by recasting them to no longer depend on Concepts. See a paper in the upcoming post-meeting mailing to see how range-based for loops will work. * A second Committee Draft (CD2) will need go out for public comment in the Spring or Summer 2010, given the amount of change required to remove Concepts. The C++0x final schedule will thus slip about one year. * No committee action was taken as to how Concepts will eventually make it into C++. While there was a bit of discussion about doing a Concepts Technical Report (TR), there was no such proposal made. Committee members seem to lean toward letting the two rival Concept teams go back to work outside of the committee process. The expectation being they will come back to the committee when they are ready to restart the standardization process. Hopefully the lessons learned about Concepts during the committee process will be taken advantage of, so future standardization of Concepts will be smoother. My personal opinion is that removing Concepts will speed the arrival of conforming C++0x compilers. GCC, for example, has already implemented much of C++0x, so their key developers are no longer faced with the difficult task of turning ConceptGCC into a production compiler, and can concentrate on remaining major features like lambdas. Although Concepts would have added a lot to C++ and Boost, Concepts would also have presented major migration challenges. I'm thinking that for most Boost libraries, migration to C++0x will now be easier and less disruptive. We need to focus on the bright side. --Beman

18 35

boost.lockfree review request
by Tim Blechmann 17 Aug '09

17 Aug '09

hi all, i would like to submit a small library of lock-free data structures for review. boost.lockfree provides implementations of lock-free data structures. lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack the code is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_… and from my personal git repository: git://tim.klingt.org/boost_lockfree.git http://tim.klingt.org/git?p=boost_lockfree.git the documentation is available at: http://tim.klingt.org/boost_lockfree/ thanks in advance, tim -- tim(a)klingt.org http://tim.klingt.org You don't have to call it music if the term shocks you. John Cage

1 0

[1.40.0] Unmerged changes delaying beta 1
by Beman Dawes 17 Aug '09

17 Aug '09

There seem to be a large number of changes to trunk that have not been merged into branches/release. Perhaps a lot of merges were forgotten after the bug fixing sprint. All of the libraries listed below are suspect, although some may just be holding changes until after the release. "svn diff" can be used to see exactly what changes have not been merged. Here is a simple Windows batch file that eases typing; perhaps someone could post a Unix equivalent. @echo off if not %1$==$ goto usage_ok echo Usage: unmerged library-name goto done :usage_ok svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/boost/%1.hpp http://svn.boost.org/svn/boost/trunk/boost/%1.hpp svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/boost/%1 http://svn.boost.org/svn/boost/trunk/boost/%1 svn diff %2 %3 %4 %5 %6 http://svn.boost.org/svn/boost/branches/release/libs/%1 http://svn.boost.org/svn/boost/trunk/libs/%1 :done If your library has changes that need to be merged, please do so right away. I'll hold off on the beta until Monday morning to give folks a chance to do merges and let tests cycle. --Beman accumulators algorithm any array asio assign bimap bind circular_buffer compatibility concept concept_check config conversion crc date_time detail disjoint_sets dynamic_bitset exception flyweight foreach format function function_types functional fusion gil graph integer io iostreams iterator lambda math mpi mpl multi_array multi_index numeric optional parameter pool preprocessor program_options property_map proto ptr_container python random range rational regex scope_exit serialization signals smart_ptr spirit statechart static_assert system thread timer tokenizer tr tuple type_traits typeof units unordered utility variant wave xpressive

13 16