- Boost - lists.boost.org

[signals] Replacing a connected slot
by Jody Hagins 25 Nov '04

25 Nov '04

I have a class that needs to react to a particular signal. However, the manner in which it handles the signal is state dependent. I would, therefore, like to change the connected slot when necessary. In general, this is not a problem. However, changing the connection inside another slot is problematic. For example, assume that Foo::bar() is already connected to signal_, and signal_() is called... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.disconnect(); current_connection_ = signal_.connect( boost::bind(&Foo::bar1, this)); } void Foo:: bar1() { std::cout << "Foo::bar1()\n"; } What I want to happen is that bar() will be called, then it will be disconnected, and bar1 will then be connected in its place. For example, given this calling sequence... signal_(); signal_(); I expect to see... Foo::bar() Foo::bar1() However, sometimes I may see... Foo::bar() Foo::bar1() Foo::bar1() because bar1() MAY get connected AFTER the place where bar() used to be connected, resulting in it also being called for the same signal invocation. What I think I want is a way to "replace" a connected slot, without disturbing anything else... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.replace_slot(&Foo::bar1, this); } This is especially important if the slot is originally connected with... signal_.connect( invocation_level, boost::bind(&Foo::bar1, this)); because I see no way to retrieve the ordering information from the connection. In any event, how do you suggest I "replace" a conected slot, while still guaranteeing that the "connection" is invoked exactly once? Thanks!!!

2 3

Re: Boost Shmem-Shared memory library first archiveavailable
by ION_G_M 25 Nov '04

25 Nov '04

Thank you Pavel for your comments, I would like to comment on some things >1. The HTML documentation does't allow to change font in browser. >2. End of document can be marked so it doesn't > look like cut in half during transmission. >3. docs 3.2: Sorry for errors and bad html. It was generated from MS Word so I will try to rewrite it using plan html. I'll change that shortly. >4. Example in 3.2: the "alignement" parameter in > segment.create() isn't found in code. I can't find the error you mention, I've just downloaded the zip file and 3.2 does not have any example. In 4.2 segment.create is missing a ",". >5. Example in 4.2: > segment.named_new<MyType> > ("MyType instance", /*name of the object*/ > 10 /*number of elements*/, > false /*if previously present, return error*/, > 0 /*ctor first argument*/, > 0 /*ctor second argument*/); a.It returns false. Exceptions are used only to indicate memory errors throwing bad_alloc. You are right there is info missing here. I will add more documentation in examples. b.If you find this approach more useful, I have no problem. I really don't like the boolean parameter, but I wanted to have a "find or create" functionality. If you like a find_or_named_new<>() additional function to indicate that approach I find it more clear than with a boolean parameters. c.The syntax you propose is better, no doubt. I don't have experience with it so to implement this I suppose named_new<> should return an proxy object with overloaded operator()() functions. Is that right? If you want to help me I'm open. If boosters prefer throwing exceptions instead or returning false no problem here. A problem I see is that my interface allows creating an array like new[]. Do you consider this necessary? You prefer a different function? Maybe the proxy object should have an operator[] that can be used to specify array allocation? > std::pair< MyType *, std::size_t> res = > segment.find_named_new< MyType > ("MyType instance"); >Why do I need the "size"? Doesn't a type have >always the same size regardless? Size contains the number of elements in case you allocate an array. with segment.named_new<MyType> ("MyType instance", /*name of the object*/ 10 /*number of elements*/, ... you allocate an array of 10 elements. so it will return 10. >6. Could you use namespace shmem_detail or so > instead of "detal" to avoid possible clashes? No problem. I've seen detail namespace in some projects so I thought it was not a problem. detail namespace is inside boost::shmem namespace so it wouldn't be necessary. You find it necessary even if detail namespace is really boost::shmem::detail? >7. exceptions.hpp: >a) file name should be shmem_exceptions.hpp or so No problem >b) does it make sense to have common base > for both exceptions there? My exception handling experience is null, so I based all in thread exception examples, where lock_error inherits from thread_exception. No problem changing this is you find it necessary. >8. offset_ptr.hpp: full_offset_ptr class >a) using char as de-facto bool class has usually > no practical advantage and may be actually slowe. No problem. You are right, with all platforms using 4 byte alignment bool and char use the same space and it can be slower I suppose due to mask operations. >b) The flag could be eliminated completely. > If m_offset == 0 it is NULL pointer and > no data allocated in shmem will starts > on the beginning. This would also eliminate > need for min_offset_ptr. The offset indicates the distance between the pointee and the this pointer of offset_ptr, so m_offset == 0 indicates a pointer pointing to itself and this is quite common in STL containers when empty, since next pointer in the end node points to end node, resulting in a m_offset = 0. Obviously this is different from a null pointer. If I change the meaning of m_offset to offset from the beginning of the segment I need the base address stored somewhere (and the base address is different in each process), so that I can convert from offset_ptr<A> to A* using get() or the constructor. Using my approach I can convert between A* and offset_ptr<A> without any additional data. Obviously, your approach is more performance friendly since m_offset does not need to be changed with each assignment and constructor. If boost people find the additional member as a waste comparing to A* <-> offset_ptr<A> conversions I would change it but I find my approach quite useful, since I don't want to deal with base addresses stored somewhere for each process when building a offset_ptr. >c) swap() could be added and other operators. Ok. I will add it. Which other operator you miss? >9. Maybe the protection of mutext from shared ptr > lib could be worked around I don't understand your point. Could you give me an example please? >10. The example in 4.3 uses very dirty C-like > approach with casts. Cannot it be rewritten > in C++ way with overloaded new? If you refer to (list_node*)segment.allocate(...) line, segment in this case is a low-level void* returning function. If you prefer an allocate<Type> approach, I don't have any problem, but remember that this segment object is of type shmem_alloc which allocs raw memory, something like when writing your own void* operator new(size_t size) for a class. If you have I workaround in mind, please let me know. >11. Some source files use Unix line ends, > some DOS line ends. Just bit strange. It's because I've tested and changed things in both windows and linux. I'll try to convert all to a common line feed. >12. The simple algorithm to find fitting memory > block may not be adequate for high-performance > apps (who are most likely to use shared > memory). You are right. The default algorithm is space-friendly, which I thought it was more important than performance for fixed size segments. You can write your own algorithm and use it since shmem_alloc is a typedef of basic_shmem_alloc<default_algo>. If you prefer another algo like segregated lists, I can try to write it, so that the user can choose the allocation algorithm. I've written the pooled allocator due to default algorithm slowness. >13. Can be be possible to identify named objects > with something else than C string? Say > wchar_t* or numeral or other templated type? Well, I've chosen a c string as an universal name, but other types could be used. Do you think that the key type should be templatized? I think that an integer key can speed up a lot searches but I have to think about which classes should be templatized. When storing other type of strings (for example std::string, I would need to build an allocator for strings in shared memory but also a std::string since it's probable that current STL won't work with Shemem STL allocator). The key meaning would be different since right now, I copy the string to shared memory but with configurable key type things are more complicated. >14. What I would like to see: >a) avoiding shmem specific containers/mutexes/etc > as much as possible. I think you can't avoid mutexes if you want to guarantee atomic memory allocation, since I have no skills to write a lock-free memory allocator. Regarding to containers, it was no my intention to write them, but I needed some of them to store name-buffer mappings and a node container to test the pooled allocator in several systems. For now, I have only succeed using shmem STL allocators in a modified Dinkum STL. STLport and libstc++ use suppose allocator::pointer to be a raw pointer, so I can't use STL containers. I've chosen internal containers to be public because I find them very useful, but if this is not accepted they can be used only for internal uses and removed from documentation. Regarding mutexes and etc... can you be more explicit? I propose mutexes to be general. If boost want to implement process-shared mutexes in other way, say in another library, I would use them, but for the moment, this is all that I have. >b) ability to "equalize" shared memory features I would need some help in this because my operating system knowledge is very limited. Mimic-ing UNIX way in windows can be very difficult, I think, unless you use a mapped file. I would need some serious help here. >c) support for inheritance in shmem using object > factories, e.g. like one in Classloader > http://s11n.net/papers/classloading_cpp.html I'll check it. Thanks for the url. >d) support for "transactions": I would like to My knowledge in transaction world is null so I can't help you with that. I suppose that a shared memory condition variable should be very interesting to notify events to other processes, but I'm afraid this is a work for more skilled programmers than me (people from boost::threads, perhaps?). As far as I know in windows is difficult to implement a shared memory condition variable, pthreads-win32 does no support it and I don't know how cygwin solves this. Thank you again for all your comments. I would like to make some changes you've suggested, so I will wait your response regarding open issues and comments from other boosters before doing any change. Regards, Ion

3 4

[iostreams(jonathan)] - using with 1.32
by Jeff Flinn 24 Nov '04

24 Nov '04

Jonathan, Do you have a version that works with the 1.32 release? If not any suggestions on modifications for use with 1.32? The two main items I see are mpl/apply_if.h and utility/select_by_size.hpp. I've change the includes for ...mpl/apply_if.h to mpl/eval_if.h and occurences of apply_if to mpl::eval_if. Is that sufficient? I've copied boost_1_31_0/utility/select_by_size.hpp to boost_1_32_0/utility/select_by_size.hpp . Is this sufficient? I've got some other compile errors but I'm not sure if they are just downstream errors caused by these issues. Thanks, Jeff

3 7

RE: [boost] preprocessor fix
by Arias Brent-P96059 24 Nov '04

24 Nov '04

I can't allow the boost mailing to pour into my work account over the holidays, so I'm unsubscribing. However, I'd like to continue our conversation - I guess offline if thats ok. I'll want to ask about updates to Besser's printable enum for starters. My e-mail is panoply(a)att.net By the way, what other portions of Boost have you contributed to besides preprocessor programming? Remember, I will have already unsubscribed before you can respond to this letter - so if you respond, please respond to the e-mail I provided. Thanks, -Brent -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Paul Mensonides Sent: Tuesday, November 23, 2004 6:53 PM To: boost(a)lists.boost.org Subject: RE: [boost] preprocessor fix > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Arias Brent-P96059 > > Have you seen > http://www.cuj.com/documents/s=8470/cujboost0306besser/? > > > Yes, I have seen that before. I did not use it for several > reasons: (1) I think the source for Besser's ENUM was not > easily available, (2) my employer gets nervous when code > "looks" too C++ oriented and gets nervous when macros become > too "involved" - which means "lengthy" (3) Besser's ENUMX > macro requires that you specify the number of parameters > (e.g. ENUM3 or ENUM23). I believe that he got rid of that (really annoying) issue. At first, that code was written more like the pp-lib itself is written--repetition of macros. That almost defeats the purpose of using the pp-lib at all. The pp-lib's strength is that it provides basic interfaces that enable you to build more complex interfaces or solutions. That basic interface provides, among other things, an abstraction layer over manual repetition of macros--so clients don't have to do it. Later on, I think that the code changed to using sequences. > Reason #3 was a real hurdle for me - because I'm trying to > provide this macro to other developers who might "rebel" if > using the macro requires from them non-intuitive new concepts > or exercises. That is, if they didn't have to count the > number of parameters in the enumeration before - they may > well reject the ENUM macro if it starts to require them to > count the entries. I definitely understand that. > So, I set out to make an ENUM macro that (1) didn't need its > entries counted by the developer and (2) had a short > definition (which makes it less daunting for "managment" buy-in). I understand that as well. :( > You said: > > >there are still basic notions of computation, etc., such as control > >flow--which is nothing but a conditional "invocation" > >of its accompanying code. Those kinds of things still apply at the > >preprocessor level. What you really needed was a way to > conditionally > >enumerate some sequence elements, not enumerate a > conditional sequence. > > My implementation was "backwards" because I was unable to > make the code compile otherwise. That is, depending on the > value of ENUMS, the following code did not compile: Sorry, I'm getting way too used to variadics. If SEQ_ENUM generates more than one comma-separated element, then the comma will interfere with the internals of EXPR_IIF. E.g. #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define EXPR_IIF(bit, expr) PRIMITIVE_CAT(EXPR_IIF_, bit)(expr) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr #define COMMA() , EXPR_IIF(0, a COMMA() b) EXPR_IIF(1, a COMMA() b) Both of these invocations will (i.e. "should") fail. For 'expr', EXPR_IIF gets the argument "a COMMA() b". That is fine because it is a single argument. However, macro arguments (by default) are expanded _before_ they replace the formal parameter instances in the replacement list. The argument "a COMMA() b" expands to "a , b". With that, the expansion procedes as follows: EXPR_IIF(0, a COMMA() b) 0 -> 0 a COMMA() b -> a , b -> PRIMITIVE_CAT(EXPR_IIF_, 0)(a , b) -> EXPR_IIF_0(a , b) // error: too many arguments The same thing occurs if 'bit' is 1, and that is what is occuring with EXPR_IIF and SEQ_ENUM. BTW, an argument that expands to include open commas (i.e. it becomes more than one argument when passed again) is called (by me) an "intermediate". Dealing with intermediates is one of the major reasons why the pp-lib source is as hacked up as it is because many preprocessors don't do the expansion order correctly. Using intermediates requires that a single argument become some known number of arguments at a fairly particular time. BTW2, for anyone that may be interested, placemarkers (which is, in essence, C99 uses to deal with empty arguments) can be used to prevent argument expansion pretty much indefinitely. E.g. #define A(x) B(x) #define B(x) C(x) #define C(x) D(x) #define D(x) x A(x) Here 'x' gets scanned for macro expansion once on entry to A, once on entry to B, once on entry to C, once on entry to D, and once again during the rescan of D's replacement list. It gets scanned for macro expansion a total of five times. However, #define A(p, x) B(, p ## x) #define B(p, x) C(, p ## x) #define C(p, x) D(, p ## x) #define D(p, x) p ## x A(, x) Here 'x' gets scanned once--during the rescan of D's replacement list. (You can't get rid of that one.) The point of this is optimization. Scanning preprocessing tokens for expansion can become expensive (especially when the scan is a no-op--which the preprocessor cannot assume). For example, the following code... #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) x ...has more computational power than the pp-lib. The 'x' argument gets scanned 260 times. If there was nine macros (instead of four), the scan count is in the millions. With thirteen, the scan count is in the billions. It is a sum of powers plus one scan on entry to A. If 'n' is the number of macros, and 'b' is the parametric base (i.e. the number or "M(M(M(M(M(M(..." in the replacement lists), then the scan count is 1 + the summation from k=0 to n-1 of b^k -- which can be rewritten as 1+(1-b^n)/(1 - b). [If anyone actually wants to see this in action, try this on a compliant preprocessor (such as gcc)... // file.c #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define SPLIT(i, im) PRIMITIVE_CAT(SPLIT_, i)(im) #define SPLIT_0(a, b) a #define SPLIT_1(a, b) b #define IS_NULLARY(x) \ SPLIT(0, CAT(IS_NULLARY_R_, IS_NULLARY_C x)) \ /**/ #define IS_NULLARY_C() 1 #define IS_NULLARY_R_1 1, ~ #define IS_NULLARY_R_IS_NULLARY_C 0, ~ #define EMPTY() #define EAT(x) #define IIF(bit) PRIMITIVE_CAT(IIF_, bit) #define IIF_0(t, f) f #define IIF_1(t, f) t #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) E(E(E(E(E(E(x)))))) #define E(x) x #define KILL(x) x #define IS_ALIVE() IS_NULLARY(KILL(())) #define TEXT(t) \ IIF(IS_ALIVE())(TEXT_A, EAT)(t) \ /**/ #define TEXT_A(t) t TEXT_B EMPTY()()(t) #define TEXT_B() TEXT KILL( A( TEXT( Boost ) ) ) gcc --pedantic -x c++ -std=c++98 -E -P file.c ...this generates 'Boost' more than 1500 times. A word of warning: don't actually do this in real code, especially with something that generates lots and lots of scans because even though 't' (called, by me, an "active argument") eventually stops expanding (referred to, by me, as "reaching a terminal state") the preprocessor still performs the scans (etc.)--even though the scans might be no-ops. Scanning, for example, the single preprocessing token + billions of times (and the invocations required to generate those scans) is no small operation--in fact, it takes a *really* *really* *really* long time to generate a single + if you don't run out of memory first (which you probably will).] Obviously, scanning itself can become expensive. It is interesting that the most important benefit of placemarkers may well be that it provides a means to prevent argument expansion rather than providing the means to pass empty arguments (which is also very useful). > > #define ENUM(name, start, entries) \ > > BOOST_PP_EXPR_IIF(ENUMS)( \ > > BOOST_PP_SEQ_ENUM( \ > > (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ > > BOOST_PP_SEQ_TAIL(entries) \ > > (LAST_ ## name } name;) \ > > ) \ > > ) \ > You said: > > >You can do it, but EXPR_IIF does not lazily evaluate its > argument (the > >syntax above is what EXPR_IIF would look like if it *did* lazily > >evaluate it argument). > >In other words, when ENUMS is 0, SEQ_ENUM will still be invoked, but > >its results will be discarded. > > I'm not sure what you are suggesting. Depending on the value > of ENUMS, the code snippet I showed above would not compile - > lazy evaluation or not. If it won't compile, then there's > nothing for me to ponder (except to use a different approach > - which happily you taught me with the TUPLE_EAT macro). :) Apologies. I was thinking about EXPR_IIF with variadics. With variadics, you can, ala: #define EXPR_IIF(bit, ...) PRIMITIVE_CAT(EXPR_IIF_, bit)(__VA_ARGS__) #define EXPR_IIF_0(...) #define EXPR_IIF_1(...) __VA_ARGS__ E.g. here the number of arguments doesn't matter. If, on the other hand, EXPR_IIF did lazy evaluation, then you can still do it without variadics: #define EXPR_IIF(bit) PRIMITIVE_CAT(EXPR_IIF_, bit) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr syntax: EXPR_IIF(bit)(expr) Here, 'expr' doesn't get expanded at all if 'bit' is 0. The side-effect of lazy evaluation is that the argument is not passed on (internally) to another macro, which means that the situation that occurs in the pp-lib-style EXPR_IIF (the first one above) cannot occur. I could redesign EXPR_IIF (etc.) using the "EXPR_IIF(bit)(expr)" form. That would allow the code to work. I still couldn't guarantee lazy evaluation, of course, because preprocessors are terrible in general. However, if I do so, I open an encapsulation hole in the workarounds for various preprocessors. Granted, there are many of those already--the pp-lib cannot actually "fix" broken preprocessors after all--but client exposure is minimized. Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: Merge of RC_1_32_0 with trunk?
by JOAQUIN LOPEZ MU?Z 24 Nov '04

24 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Miércoles, Noviembre 24, 2004 6:00 pm Asunto: Re: [boost] Re: Merge of RC_1_32_0 with trunk? > Joaquín Mª López Muñoz writes: > > OK. A note of warning, though: during the last days before the > release,> Aleksey commited some changes to the docs directly in > the branch. These > > changes affect: > > > > 1. The main page (portions of the release notes) > > 2. The MPL docs > > 3. Boost.MultiIndex (some docs pages) > > 4. Other libraries? > > > > I'm sure Aleksey'll take care of 1 and 2, > > I'm going to take care of everything. > Oh, I'm afraid I've already done the job for multi_index :( So, you can safely skip that library. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

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

24 Nov '04

1.32 didn't make a difference. Thanks for the suggestion though. -----Original Message----- From: Tim Laplaca Sent: Wednesday, November 24, 2004 12:39 PM To: 'boost(a)lists.boost.org' Subject: RE: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? I think I'm on 1.31, so I'll give 1.32 a try. Thanks! -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, November 24, 2004 10:09 AM To: boost(a)lists.boost.org Subject: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? What version of Boost? I seem to remember a Boost.Threads thread local storage problem that would cause a problem after about that many threads, which should be fixed in the latest release (1.32 from only a few days ago). I'm not sure if that's your problem, but if it is I recommend giving 1.32 a try. Mike "Tim Laplaca" <tlaplaca(a)voiceglo.com> wrote in message news:5D27A17F676E8648B2C4CB5DC4E40E0D9338DD@porsche.corp.voiceglo.com... > > 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. > > It doesn't matter if I spawn them one after each other, or only 10 > at a > time, or if the threads only last 1 second or if they all stick > around > until the 283rd thread is spawned. Every combination I've tried > results > in the prog aborting at about the 283rd thread spawn. > > Does this sound familiar to anybody? > > Is there something my thread must do to properly shut itself down? > Does > it need to call some kind of procedure to announce it is going away > for > proper cleanup? I couldn't see anything in the examples like that. > > And is there documentation explaining the examples? I failed to > find > any. > > My thread procedure: > > > void updatethread(void* inparams) > { > > thread_params *tparam; > tparam=(thread_params *)inparams; > > int local_threadid = tparam->param1; > std::string DID = tparam->param2; > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " running. " > "UPDATE for " << DID << std::endl; > } > > > // wait some secs (just for debug, remove when real work is > being done) > boost::xtime xt; > boost::xtime_get(&xt, boost::TIME_UTC); > xt.sec += 2; > boost::thread::sleep(xt); > > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " Exiting. " << > std::endl; > } > > > { > boost::mutex::scoped_lock scoped_lock(numthreads_mutex); > --activethreads; > } > > } > > > MAIN calls it with this: > > //spawn thread > tparam.param1=threadid; > tparam.param2=dids[i]; > boost::thread *pt; > pt = thrds.create_thread(thread_adapter(&updatethread, > (void*)&tparam)); > > Thanks, > Tim > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

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

24 Nov '04

I think I'm on 1.31, so I'll give 1.32 a try. Thanks! -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Wednesday, November 24, 2004 10:09 AM To: boost(a)lists.boost.org Subject: [boost] Re: Thread: Why is my prog aborting after 283 or so threads? What version of Boost? I seem to remember a Boost.Threads thread local storage problem that would cause a problem after about that many threads, which should be fixed in the latest release (1.32 from only a few days ago). I'm not sure if that's your problem, but if it is I recommend giving 1.32 a try. Mike "Tim Laplaca" <tlaplaca(a)voiceglo.com> wrote in message news:5D27A17F676E8648B2C4CB5DC4E40E0D9338DD@porsche.corp.voiceglo.com... > > 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. > > It doesn't matter if I spawn them one after each other, or only 10 > at a > time, or if the threads only last 1 second or if they all stick > around > until the 283rd thread is spawned. Every combination I've tried > results > in the prog aborting at about the 283rd thread spawn. > > Does this sound familiar to anybody? > > Is there something my thread must do to properly shut itself down? > Does > it need to call some kind of procedure to announce it is going away > for > proper cleanup? I couldn't see anything in the examples like that. > > And is there documentation explaining the examples? I failed to > find > any. > > My thread procedure: > > > void updatethread(void* inparams) > { > > thread_params *tparam; > tparam=(thread_params *)inparams; > > int local_threadid = tparam->param1; > std::string DID = tparam->param2; > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " running. " > "UPDATE for " << DID << std::endl; > } > > > // wait some secs (just for debug, remove when real work is > being done) > boost::xtime xt; > boost::xtime_get(&xt, boost::TIME_UTC); > xt.sec += 2; > boost::thread::sleep(xt); > > > > { > boost::mutex::scoped_lock scoped_lock(io_mutex); > std::cout << " Thread:" << local_threadid << " Exiting. " << > std::endl; > } > > > { > boost::mutex::scoped_lock scoped_lock(numthreads_mutex); > --activethreads; > } > > } > > > MAIN calls it with this: > > //spawn thread > tparam.param1=threadid; > tparam.param2=dids[i]; > boost::thread *pt; > pt = thrds.create_thread(thread_adapter(&updatethread, > (void*)&tparam)); > > Thanks, > Tim > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[serialization] Enhanced Documentaiton for Argument Dependent Lookup?
by Jeff Flinn 24 Nov '04

24 Nov '04

Robert, The release notes page makes reference to: Differences from Draft #20 - Support for Argument Dependent Looup for serialization override invocations. - Enhanced documentation to help explain usage of the above. Where might this be found? A link here would be useful. Note: the misspelling of Lookup above is in the page. Thanks, Jeff

2 3

[graph] non-recursive version of undirected_dfs
by Synge Todo 24 Nov '04

24 Nov '04

Dear Boosters, I'm posting a non-recursive version of undirected_dfs, which should have advantages in space and time over the current implementation based on recursion, especially for huge graphs. It's a direct counterpart of the non-recursive version of depth_first_search for digraphs. I have confirmed that libs/graph/example/undirected_dfs.cpp as well as my own programs using undirected_dfs reproduce the identical outputs as those with the original recursive version. Best regards, Synge *** boost/graph/undirected_dfs.hpp 6 Aug 2004 05:02:41 -0000 1.1.1.1 --- boost/graph/undirected_dfs.hpp 19 Aug 2004 05:11:32 -0000 1.2 *************** *** 28,38 **** --- 28,106 ---- #define BOOST_GRAPH_UNDIRECTED_DFS_HPP #include <boost/graph/depth_first_search.hpp> + #include <vector> namespace boost { namespace detail { + // Define BOOST_RECURSIVE_DFS to use older, recursive version. + // It is retained for a while in order to perform performance + // comparison. + #ifndef BOOST_RECURSIVE_DFS + + template <typename IncidenceGraph, typename DFSVisitor, + typename VertexColorMap, typename EdgeColorMap> + void undir_dfv_impl + (const IncidenceGraph& g, + typename graph_traits<IncidenceGraph>::vertex_descriptor u, + DFSVisitor& vis, + VertexColorMap vertex_color, + EdgeColorMap edge_color) + { + function_requires<IncidenceGraphConcept<IncidenceGraph> >(); + function_requires<DFSVisitorConcept<DFSVisitor, IncidenceGraph> >(); + typedef typename graph_traits<IncidenceGraph>::vertex_descriptor Vertex; + typedef typename graph_traits<IncidenceGraph>::edge_descriptor Edge; + function_requires<ReadWritePropertyMapConcept<VertexColorMap,Vertex> >(); + function_requires<ReadWritePropertyMapConcept<EdgeColorMap,Edge> >(); + typedef typename property_traits<VertexColorMap>::value_type ColorValue; + typedef typename property_traits<EdgeColorMap>::value_type EColorValue; + function_requires< ColorValueConcept<ColorValue> >(); + function_requires< ColorValueConcept<EColorValue> >(); + typedef color_traits<ColorValue> Color; + typedef color_traits<EColorValue> EColor; + typedef typename graph_traits<IncidenceGraph>::out_edge_iterator Iter; + typedef std::pair<Vertex, std::pair<Iter, Iter> > VertexInfo; + + std::vector<VertexInfo> stack; + + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + stack.push_back(std::make_pair(u, out_edges(u, g))); + while (!stack.empty()) { + VertexInfo& back = stack.back(); + u = back.first; + Iter ei, ei_end; + tie(ei, ei_end) = back.second; + stack.pop_back(); + while (ei != ei_end) { + Vertex v = target(*ei, g); + vis.examine_edge(*ei, g); + ColorValue v_color = get(vertex_color, v); + EColorValue uv_color = get(edge_color, *ei); + put(edge_color, *ei, EColor::black()); + if (v_color == Color::white()) { + vis.tree_edge(*ei, g); + stack.push_back(std::make_pair(u, std::make_pair(++ei, ei_end))); + u = v; + put(vertex_color, u, Color::gray()); + vis.discover_vertex(u, g); + tie(ei, ei_end) = out_edges(u, g); + } else if (v_color == Color::gray()) { + if (uv_color == EColor::white()) vis.back_edge(*ei, g); + ++ei; + } else { // if (v_color == Color::black()) + ++ei; + } + } + put(vertex_color, u, Color::black()); + vis.finish_vertex(u, g); + } + } + + #else // BOOST_RECURSIVE_DFS + template <typename IncidenceGraph, typename DFSVisitor, typename VertexColorMap, typename EdgeColorMap> void undir_dfv_impl *************** *** 69,74 **** --- 137,145 ---- } put(vertex_color, u, Color::black()); vis.finish_vertex(u, g); } + + #endif // ! BOOST_RECURSIVE_DFS + } // namespace detail template <typename Graph, typename DFSVisitor,

2 2

[Boost-bugs] [ boost-Bugs-1072605 ] condition variables and recursive_mutex
by SourceForge.net 24 Nov '04

24 Nov '04

Bugs item #1072605, was opened at 2004-11-24 09:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1072605&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: condition variables and recursive_mutex Initial Comment: Hello - I've been working through the Boost.Threads example code, I'm new to the library, but i think i found a bug in the monitor.cpp example (boost_1_31_0/libs/thread/example/monitor.cpp) . When run using a recursive_mutex, the program hangs more often than not. It appears that the cuplrits are the calls to cond.wait(lk). For the recursive_mutex case, it appears that in some circumstances, these fall through without actually waiting for a change in the state of the lock lk. Attached is an example which is somewhat simpler that the one in monitor.cpp, but yields the same problem. Note that I'm compiling on a redhat ws3 system, with: Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42) and linking against libboost_thread-gcc-mt.so Typical output as given is: sent 100, received 100 sender waits 99, receiver waits 49944 I.e. close to 50k calls to cond.wait() in the receiver thread) When recompiling with "recursive_mutex" replaced by "mutex", the number of waits is on the order of the number of receives (i.e. in the range 0-100) Any help/insight is appreciated. Regards, Bill Moser billm(a)ll.mit.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1072605&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0