- Boost - lists.boost.org

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 29 Nov '04

29 Nov '04

Thanks for the link. I'm not sure it applies though; the prog isn't spawning the threads simultaneously, so it shouldn't be taking many resources. I've found that even if I only have one thread spawned at one time (where the previous thread has died out before the new one is spawned) it still aborts at the same place. Over the holiday I pared my program down to just the thread spawning, and on my Mandrake setup at home it dies at the nice even (computer) number of 256 threads. The same pared-down prog dies on my work Fedora Core 3 machine at 405. Under Windows, it doesn't ever seem to die. I'm getting pretty convinced this is a bug in the boost library that manifests itself only under Linux, and not my code. Perhaps resources are not being properly released when the threads are dying out. Since the prog is pretty small, I'll include it here. It spawns a thread every second, and each thread only last one second. #include <iostream> #include <string> #include <stdlib.h> // for multithreading #include <boost/thread/mutex.hpp> #include <boost/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/bind.hpp> int totalthreads = 0; boost::mutex io_mutex; // iostreams boost::mutex numthreads_mutex; // for changing value of numthreads boost::mutex threadid_mutex; // for manipulating thread_id using namespace std; void threadfunc() { // wait some secs boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread Exiting. " << std::endl; } } main() { boost::thread_group thrds; boost::xtime xt; int maxthreads=99999; // ******************************** // Main thread-spawning loop for (int i=0; i<=maxthreads; i++) { totalthreads++; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << "MAIN: Thread:" << totalthreads << " being spawned... " << std::endl; } thrds.create_thread( &threadfunc); // wait some seconds boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); } // end thread-spawning for loop thrds.join_all(); std::cout << "Done." << std::endl; } Here's the Makefile I build it with: lib = /usr/local/lib/libboost_thread-gcc-mt-1_32.so threadtest : threadtest.o g++ $(lib) $(lib2) -o threadtest threadtest.o -ldl -lc -lpthread threadtest.o : threadtest.cpp g++ -Wall threadtest.cpp -I/usr/local/include/boost-1_32 -pthread -c -w -O -o threadtest.o -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov Sent: Friday, November 26, 2004 2:07 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? Tim Laplaca wrote: > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after > spawning 283 or so threads, it stops running and 'Aborted' is printed. Take a look at: http://www.kegel.com/c10k.html#threaded and check your sizes. -- Alexander Nasonov _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Re: Another logo proposal
by Beman Dawes 29 Nov '04

29 Nov '04

At 01:11 PM 11/23/2004, Beman Dawes wrote: >At 06:18 PM 11/22/2004, Rich Johnson wrote: >> >>On Monday, November 22, 2004, at 04:02 PM, JOAQUIN LOPEZ MU?Z wrote: >> >>>> Is there a single color restriction for ease of printing? If not >>>> adding a third '+' in a different color (or perhaps in outline) >>>> would >>>> further emphasize building on C++. >>> >>> You mean, like the version attached? >>> I don't know, it kind of looks too irregularly shaped. Not >>> so blocky as the other designs. >>> >>> Joaquín M López Muñoz >>> Telefónica, Investigación y Desarrollo >>> <boost.gif> >> >>I was thinking more like: >> >> >> >> >> >>Which yields two steps up. I like that a bit. Is anyone keeping a list of the more likely candidates? --Beman

6 10

RE: [boost] Re: [ANN] Phoenix-2 Preview
by Eyal Farago 29 Nov '04

29 Nov '04

I'm not that familiar with phoenix (yet) but I think your implementation fails to handle const arguments. I think that the return type deduction mechanizm should first 'remove_cv' the argument type, then get the appropriate type from your existing metafunction, then 'add_const' if the argument was const and then 'add_reference'. (all of these can be easily done using boost::mpl and boost::type_traits libs). am I missing anything? maybe the framework does this for you? eyal. -----Original Message----- From: Reece Dunn [mailto:msclrhd@hotmail.com] Sent: Monday, November 29, 2004 2:06 PM To: boost(a)lists.boost.org Cc: spirit-general(a)lists.sourceforge.net; spirit-devel(a)lists.sourceforge.net Subject: [boost] Re: [ANN] Phoenix-2 Preview Joel wrote: > Reece Dunn wrote: >> I have written lazy veraions of pair.first and pair.second (see >> attachment). > > Nice! Seems like a beginning of a utility module. If you'd like > to submit it as part of the library, I'd need a test program. Done. Note that the libs/spirit/phoenix/test/Jamfile.v2 needs + # bring in rules for testing + import testing ; at the top to allow you to run bjam from that directory, otherwise it complains about 'run' being unrecognised. > I'd also > request conformance with the implied coding styles for the sake > of consistency. Done. > Many thanks! :) Regards, Reece

1 0

[repost][aligned_storage] problem for GCC 3.2 and proposed solution
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

Allow me to repost this, since seems it has gone thru the list indavertently. I'd be grateful if people with various versions of GCC can try the snippet so as to determine to which extent the problem shows. Original post follows: The following program: #include <boost/aligned_storage.hpp> struct foo { foo(int x){} private: boost::aligned_storage<sizeof(int)> a; }; int main() { foo f(5); return 0; } fails in GCC 3.2 20020927 with the error: /usr/local/boost_1_32_0/boost/aligned_storage.hpp: In function `int main()': /usr/local/boost_1_32_0/boost/aligned_storage.hpp:75: ` boost::aligned_storage<size_, alignment_>::aligned_storage(const boost::aligned_storage<size_, alignment_>&) [with unsigned int size_ = 4, unsigned int alignment_ = 0ffffffff]' is private Digging into aligned_storage.hpp, I find the following workaround: #if !BOOST_WORKAROUND(__GNUC__, <= 2) private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #else // gcc2.x public: // _should_ be noncopyable, but GCC compiler emits error aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #endif // gcc2.x workaround So, it seems like the problem was known but incorrectly assumed to affect GCC 2.x only. Anyone objects to extending the workaround to GCC 3.x? It remains to know whether this problem (that seems like an incorrect application of the copy ellision rules) persists in GCC 3.4.x, and in case it is fixed, which last version is for which we should have the workaround. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Website MPL Docs.
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

----- Mensaje original ----- De: Thomas Witt <witt(a)acm.org> Fecha: Viernes, Noviembre 26, 2004 9:20 pm Asunto: [boost] Website MPL Docs. > > Maybe I am just going nuts but the mpl doc links on the website > seem to > be broken. > > http://www.boost.org/libs/libraries.htm > > contains a link to: > > http://www.boost.org/libs/mpl/doc/index.html > > This document seems to be outdated and all the > links in this document seem to be broken. > > The following url seems to point to the current docs > > http://www.boost.org/libs/mpl/doc > > I am lost > I think your browser cache is playing tricks on you. Everything looks OK from mine. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

[MPL] document autogeneration
by Cromwell Enage 29 Nov '04

29 Nov '04

Since the MPL docs are autogenerated using ReST, I'd like to know how to make the documentation for my own numeric constants conform to the new format. Access to the ReST sources themselves (even if they're only on mywikinet), accompanied by the steps needed to configure Docutils, would be best. TIA! Cromwell Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

DocBook local XSL stylesheets
by Edward Diener 29 Nov '04

29 Nov '04

It appears that the DocBook local XSL stylesheets at the DocBook SourceForge site only has a setup for Unix/Linux systems, not Windows. If this is the case, it should be mentioned in BoostBook documentation.

1 0

DocBook DTD distribution
by Edward Diener 29 Nov '04

29 Nov '04

In the DocBook documentation for Boost for configuring local XSL and DTD distributions it says that the DocBook DTD is at the OASIS DocBook site at http://www.oasis-open.org/docbook/xml/4.2/index.shtml . However clicking this link gets a Resource not found message on the Oasis web site. However using http://www.oasis-open.org/docbook/xml/4.2 works for me, and http://www.oasis-open.org/docbook/xml/4.2/docbook-xml-4.2.zip is the actual zip file. Perhaps the document needs updating.

1 0

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

----- Mensaje original ----- De: Stefan Slapeta <stefan_nospam_(a)slapeta.com> Fecha: Domingo, Noviembre 28, 2004 11:25 pm Asunto: [boost] Re: Logos - Last Minute Change of Heart > JOAQUIN LOPEZ MU?Z wrote: > > > Anyway, I've just forged anoher idea. Not that I like > > it much, but the idea is a little different and might > > please some --sort of ++ breaking the barrier of sound > > or something. > > > > Sorry - blue and red don't harmonise! > Is it only the color you don't like, or also the rest? :) I mean, changing colors is easy enough, see attached example for instance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Re: Logos - Last Minute Change of Heart
by JOAQUIN LOPEZ MU?Z 28 Nov '04

28 Nov '04

----- Mensaje original ----- De: Peter Petrov <ppetrov(a)ppetrov.com> Fecha: Lunes, Noviembre 29, 2004 0:07 am Asunto: [boost] Re: Logos - Last Minute Change of Heart > JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes: > > > > Why don't you try removing the distant parts of the circles > > > surrounding the + > > > signs (so that they look more like C's, rather than O's). > > > > > > > I think it's going to look clumsy, as the distants parts > > of the circles are mostly covered. In order to see something, > > the circles would have to be chopped way too much, roughly > > between 12:00 and 6:00, if you know what I mean. > > Mostly, but not completely. I played a little with your image and > removed them. > See the result, I think it looks better: > > http://www.ppetrov.com/temp/png00027pp.png > > Here is the original: > > http://www.ppetrov.com/temp/png00027.png > Umm... yes, I agree it looks cleaner. Would you mind changing it in the Wiki? As I said, I cannot do it myself. Thanx! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0