- Boost - lists.boost.org

Re: [boost] threads: how to remotely kill a thread?
by David M. Cotter 10 Oct '09

10 Oct '09

yes i have seen the error of my ways, and am now using thread.interrupt () and i sprinkle interruption_point() in my inner loops of the thread thanks for the feedback. -dave On Oct 9, 2009, at 9:20 PM, Yigong Liu wrote: > It is kind of dangerous for one thread to kill another thread > forcefully or directly, since the 2nd thread may be in the middle of > holding a system resource or changing some state. Killing it may > left the system in corrupted state. better using "cooperative" > shutdown, the 1st thread sends the 2nd thread some notification, > either thru shared state or interrupt. For similar reasons, java > deprecated many thread api (http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.h… > ). > > On Fri, Oct 2, 2009 at 9:16 AM, Andrey Semashev <andrey.semashev(a)gmail.com > > wrote: > David M. Cotter wrote: > say i'm on the main thread, and i've got a thread::id of some other > preemptive thread. i do not have the actual boost::thread object > any more. > > and i want to unceremoniously kill that thread. like right now. > > how do i kill it? i don't see a way to recover the actual > boost::thread from the thread::id. but even if i could, and then > call thread.interrupt(), that's more of a polite request which is > free to be ignored, rather than a you_must_die_now() thing. > > The main problem with killing threads is that it doesn't unwind the > stack and thus breaks RAII. Therefore the best "official" way to > terminate the thread in C++ is to interrupt it. If you want to do it > the hard way, you're in C world with pthread_kill and alikes.

1 0

[fusion] accumulate vs. std::accumulate
by Christoph Heindl 10 Oct '09

10 Oct '09

Hi, I'm currently confronted with an issue raised before [1] on this list: boost::fusion::accumulate takes its arguments in reverse order compared to std::accumulate. The issue is still marked as 'new' on trac [2]. What are the chances to have this issue fixed for the next release? Kind regards, Christoph [1] http://lists.boost.org/Archives/boost/2008/09/142490.php [2] https://svn.boost.org/trac/boost/ticket/2355

1 0

[trunk] Missing Jamfile in Boost Root Directory
by Dean Michael Berris 10 Oct '09

10 Oct '09

Hi everyone, I just did an SVN update to the latest in Boost's trunk and I don't see a Jamfile in the root directory anymore. I ask because I do this in my project Jamroot, which used to work: import os ; local BOOST_ROOT = [ os.environ BOOST_ROOT ] ; use-project /boost : $(BOOST_ROOT) ; But now when running bjam it complains that it can't see a Jamfile in the BOOST_ROOT directory. Any workarounds for this? TIA -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

2 1

[MPI?] which API should i use for this?
by David M. Cotter 10 Oct '09

10 Oct '09

I have a need to send an "event" to the "main thread's event loop". this may be done from a preemptive thread, a cooperative thread, a timer, or even the main thread itself. i want it to be posted into the event stream and handled in the order that events get processed on the main thread. would i use 'MPI'? or 'interprocess'? or is there a 'thread' way to do this? if it's MPI, what would be the right call? i'm coming from Mac land where i have traditionally used PostEventToQueue()

5 5

[Boost.Units] non-integral unit exponents
by Belcourt, Kenneth 09 Oct '09

09 Oct '09

Hi, I'd like to use Boost.Units but am unsure whether I can declare a unit like this: W/m^2 Pa^0.25 K^1.523 In addition, I'd like the ability to change the pressure (Pa) and temperature (K) coefficients at runtime (user supplied input might change the default coefficients). Are these things possible with Boost.Units and, if so, could someone point me to an example? (I need this for nucleate boiling curves). Thanks. -- Noel

2 1

threads: linking on OSX
by David M. Cotter 09 Oct '09

09 Oct '09

I followed the instructions from here: http://www.boost.org/doc/libs/1_40_0/more/getting_started/unix-variants.htm… and it spent a bunch of time compiling everything. no errors. yay. so then i go to link my program, i added <boost dir>/stage/lib/ libboost_thread.a to my project, cuz that's how you static link, right? where <boost dir> is the location of the boost installation but it says: <boost dir>/bin.v2/libs/thread/build/darwin-4.2.1/release/threading- multi/libboost_thread.dylib, file is not of required architecture Undefined symbols: <long list of all the boost symbols i used> interesting that even by adding the .a file, it went and found the dylib? is that normal? anyway, wrong architecture?? how do i make it build universal? (PPC plus intel? and what's with the missing symbols? i'm not really a n00b, i just appear to be one today.

3 4

[parameter] Ticket #3114
by Jeremiah Willcock 09 Oct '09

09 Oct '09

Would it be possible to have the feature requested by ticket #3114 (https://svn.boost.org/trac/boost/ticket/3114) implemented? This would make the Boost.Parameter library much more useful for situations where default argument types do not always exist. Thank you. -- Jeremiah Willcock

1 0

[Property map] 1.40.0 breaks boost.graph python bindings
by John Reid 09 Oct '09

09 Oct '09

I'm using gcc 4.2.4 on Ubuntu. The boost.graph python bindings (http://www.osl.iu.edu/~dgregor/bgl-python/) work fine with boost 1.39. When I try with boost 1.40 I get many errors such as the following: ./boost/graph/python/resizable_property_map.hpp:101: error: ‘class boost::vector_property_map< boost::default_color_type, boost::graph::python::basic_index_map< boost::graph::python::basic_descriptor<boost::detail::edge_desc_impl<boost::bidirectional_tag, void *>, boost::bidirectionalS>, boost::adj_list_edge_property_map< boost::bidirectional_tag, long unsigned int, const long unsigned int &, void *, const boost::property<boost::edge_index_t, long unsigned int, boost::no_property>, boost ::edge_index_t>>>’ has no member named ‘get_store’ Does anyone know what changed between 1.39 and 1.40 to break this? The Readme.txt that comes with boost 1.40 suggests that nothing was updated in the property map library. BTW it doesn't compile with gcc 4.3 either but then neither does it compile with boost 1.39 (albeit for different reasons). I can provide all of the error messages if needed. John.

1 0

[1.41.0] Cleaning up inspection errors
by Beman Dawes 09 Oct '09

09 Oct '09

The Inspection Report is showing 1292 problems reported. I'd like to drive that number way lower for the 1.41.0 release. The "Worst Offenders" list is: test (254) regression (145) gil (140) build (116) proto (75) See http://boost.cowic.de/rc/inspect-trunk.html Developers, please fix any problems in your library. Thanks, --Beman

2 2

[program-options] Ticket #1132, multitoken() and zero_token()
by Sascha Ochsenknecht 09 Oct '09

09 Oct '09

Hello, I would like to have an option which allows multi token but not multiple occurrences of the option or at least a way to distinguish the occurrences: E.g. something like: program.exe --option value1 value2 I tried the following: 1) desc.add_options()("option", value<string>()->multitoken(), "help"); With the above command line I get exception: multiple values not allowed 2) desc.add_options()("option", value<vector<string> >(), "help"); Command line is parsed without error but only value1 is stored in the vector -> ERROR, should report 3) desc.add_options()("option", value<vector<string> >()->multitoken(), "help"); Command line is parsed without error both values are stored in the vector, but program.exe --option value1 --option value2 and program.exe --option value1 value2 leads to the same vector contents. With the current version it isn't possible to distinguish to occurrences of a certain option and it is not possible to implement an option which has the multitoken attribute but isn't allowed to occur several times. I'm willing to work on a patch for this issue, but first I want to discuss how to solve this, i.e. how the library should behave. The problem is possibly that specifying a list or vector implies that an option can occur multiple times. I think maybe following solution could work: 1) desc.add_options()("option", value<vector<string> >(), "help"); multiple occurrences of the option are allowed and pushed to the vector but only one value per option occurrence (like it is implemented now) 2) desc.add_options()("option", value<vector<string> >()->multitoken(), "help"); multiple occurrences of the option are NOT allowed, the multiple tokens/values are pushed to the vector 3) desc.add_options()("option", value<vector<vector<string> > >()->multitoken(), "help"); multiple occurrences of the option are allowed, the multiple tokens/values are pushed to the inner vector E.g. program.exe --option value1 value2 --option value3 --option value4 value5 This would result in the following storage sheme: { { value1, value2 } { value3 } { value4 value5 } } I'm not sure if a could become a friend of this implementation ... but it would work at least. Another way would be to join the multitokens into a single string: { "value1 value2" "value3" "value4 value5" } .. but this I don't like :-(. What do you think? Thanks & regards, Sascha PS: Is somebody working on ticket #1132 ??

1 0