> From: Alexander Terekhov <[EMAIL PROTECTED]> > "William E. Kempf" wrote: > [...] > > > I think that a reasonable requirement that we already mentioned several > > > times is that the ID should be CopyConstructible, Assignable and > > > LessThanComparable, for use in sets/maps. > > > > This misses the need for outputting in diagnostic messages, for one thing. > > And all of this can be supplied directly by boost::thread with no need for > > a boost::thead::id. I just want to make sure we've not missed some other > > need, which may mean we DO need a seperate id type. > > I, for one, DO need something along the lines of: > > http://groups.google.com/groups?selm=3D613D44.9B67916%40web.de > (Subject: Re: High level thread design question) > > Well, "futures" aside for a moment, how about the following "concept" > (just an illustration/ideas): > > new_thread{< thread >}( function{, ...args...} ); > > {exception_propagator< exception{, ...exceptions...} >::} > {thread_attr_object.}new_thread( function{, args} ); > > {exception_propagator< thread, exception{, ...exceptions...} >::} > {thread_attr_object.}new_thread( function{, args} ); > > For example, given: > > void operation(); // Oh, BTW, in the next release this might throw std::bad_alloc > > We could then have: > > a) no propagation of exceptions on join ["default"]: > > new_thread( operation ); > > new_thread< my_fancy_thread >( operation ); > > thread::attr().set_name( "007" ). > new_thread( operation ); > > my_fancy_thread::attr().set_something( something ). > new_thread( operation ); > > > b) propagation of exceptions [specified at thread CREATION point] on join: > > exception_propagator< std::bad_alloc >:: > new_thread( operation ); > > exception_propagator< my_fancy_thread,std::bad_alloc >:: > new_thread( operation ); > > exception_propagator< std::bad_alloc >:: > attr().set_name( "007" ). > new_thread( operation ); > > exception_propagator< my_fancy_thread,std::bad_alloc >:: > attr().set_something( something ). > new_thread( operation );
Planned, but not as part of boost::thread. Like parameter passing, I still believe this logic belongs in the function object. I just plan to develop a reusable component for building such function objects, in order to make life easy on the user. William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost