- Boost - lists.boost.org

Correct Mutext Destroy Behaviour, Pthreads and Boost
by Robert Bell 01 Jun '15

01 Jun '15

If an object is implemented to support reference counting, and has an internal raw pthread mutex, the open group is pretty clear in the pthread_mutex_destroy doc on what different implementations must ensure (http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_dest…) Note the following statement at the bottom: "A mutex can be destroyed immediately after it is unlocked. For example, consider the following code:" obj_done(struct obj *op) { pthread_mutex_lock(&op->om); if (--op->refcnt == 0) { pthread_mutex_unlock(&op->om); (A) pthread_mutex_destroy(&op->om); (B) free(op); } else (C) pthread_mutex_unlock(&op->om); } In this case obj is reference counted and obj_done() is called whenever a reference to the object is dropped. Implementations are required to allow an object to be destroyed and freed and potentially unmapped (for example, lines A and B) immediately after the object is unlocked (line C)." On moving some of my underlying libraries to Boost, I took a look at Boost's Mutex object. The implementation of the Mutex object's destructor call does: ~mutex() { int const res = posix::pthread_mutex_destroy(&m); boost::ignore_unused(res); BOOST_ASSERT(!res); } My question centres on whether Boost's implementation violates the open group's requirement. The calls to posix::pthread_mutex_destroy (Boost's wrapper), usually perform a straight-through call to ::pthread_mutex_destroy, but it occurs inside the destructor, and so does this call occur "immediately after" an unlock by the group's definition? In straight pthreads, if I want to make sure I can rely on various implementations of the standard, I can simply do exactly what the open group says, unlock, and the next line destroy. But in the case of Boost, is it safe to do something like: mutex->unlock(); delete mutex_; One thing I did note of interest is that Apple's implementation seems to lock the mutex from within the destroy call, which is curious: int pthread_mutex_destroy(pthread_mutex_t *mutex) { int res; LOCK(mutex->lock); if (mutex->sig == _PTHREAD_MUTEX_SIG) { if (mutex->owner == (pthread_t)NULL && mutex->busy == (pthread_cond_t *)NULL) { mutex->sig = _PTHREAD_NO_SIG; res = ESUCCESS; } else res = EBUSY; } else res = EINVAL; UNLOCK(mutex->lock); return (res); } There seems, generally, to be a good deal of confusion surrounding when it is safe to destroy the resources associated with a mutex, and most people offer widely inaccurate comments based largely on opinion. My question points to whether code adjacency is a requirement of correct behaviour in some implementations, and if not, why not? If I have missed an obvious explanation somewhere, my apologies. I read through the different patterns of Boost threading listed in the documentation, but was not convinced the question was addressed. Thanks in advance…

4 5

Resources available for testing on 64-bit MSVC
by pfultz2 01 Jun '15

01 Jun '15

Hello, Recently, I have been working on adding MSVC support for the Fit library, and I have been fairly successful. Using the VMs at modern.ie, I was to able to get all the tests to pass on 32-bit Visual Studio 2015 RC. Unfortunately, a few tests fail on the 64-bit MSVC, and I have been unable to find a VM I can use to debug the problem. All the VMs at modern.ie are 32-bit, it seems. Does anyone know of resources available to test and debug libraries with 64-bit MSVC? Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Resources-available-for-testing-on-64-bi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[next gen future-promise] What to call the monadic return type?
by Niall Douglas 01 Jun '15

01 Jun '15

Dear list, As AFIO looks likely to be finally getting a community review soon, I've made a start on a final non-allocating constexpr-collapsing next generation future-promise such that the AFIO you review is "API final". You may remember my experimentations on those from: http://boost.2283326.n4.nabble.com/Non-allocating-future-promise-td466 8339.html. Essentially the win is that future-promise generates no code at all on recent C++ 11 compilers unless it has to [1], and when it does it generates an optimally minimal set with no memory allocation unless T does so. This should make these future-promises several orders of magnitude faster than the current ones in the C++ standard and solve their scalability problems for use with things like ASIO. They also have major wins for resumable functions which currently always construct a promise every resumable function entry - these next gen future-promises should completely vanish if the resumable function never suspends, saving a few hundred cycles each call. Anyway, my earlier experiments were all very promising, but they all had one big problem: the effect on compile time. My final design is therefore ridiculously simple: a future<T> can return only these options: * A T. * An error_code (i.e. non-type erased error, optimally lightweight) * An exception_ptr (i.e. type erased exception type, allocates memory, you should avoid this if you want performance) In other words, it's a fixed function monad where the expected return is T, and the unexpected return can be either exception_ptr or error_code. The next gen future provides Haskell type monadic operations similar to Boost.Thread + Boost.Expected, and thanks to the constexpr collapse this: future<int> test() { future<int> f(5); return f; } test().get(); ... turns into a "mov $5, %eax", so future<T> is now also a lightweight monadic return transport capable of being directly constructed. In case you might want to know why a monadic return transport might be so useful as to be a whole new design idiom for C++ 11, try reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat esfromfunctions. However, future<T> doesn't seem named very "monadic", so I am inclined to turn future<T> into a subclass of a type better named. Options are: * result<T> * maybe<T> Or anything else you guys can think of? future<T> is then a very simple subclass of the monadic implementation type, and is simply some type sugar for promise<T> to use to construct a future<T>. Let the bike shedding begin! And my thanks in advance. Niall [1]: Compiler optimiser bugs notwithstanding. Currently only very recent GCCs get this pattern right. clang isn't bad and spills a dozen or so completely unnecessary opcodes, and I'll follow up with Chandler with some bug reports to get clang fixed. Poor old MSVC spits out about 3000 lines of assembler, it can't do constexpr folding at all yet. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

16 122

RFC: Separating Boost.Python from Boost
by Stefan Seefeld 31 May '15

31 May '15

Hello, as I have mentioned here before, I would very much like to continue the modularization effort, by fully separating the Boost.Python project from the rest of Boost. For avoidance of doubt: my intent is not to remove Boost.Python out of the Boost organization. Rather, I would like to separate the build and release processes. For the sake of keeping the discussion focused, I would like to avoid getting into too many (technical) details (there already is a related discussion on the Boost.Build list). Rather, I would like to know whether people here (and Boost.Python users in particular) have any particular thoughts about this proposal. Any strong reasons not to move forward with this ? Things to consider while doing it ? Etc. (My hope is that if the operation succeeds, other Boost libraries may want to do the same, which would help Boost in the long term to become more manageable.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

18 62

Thoughts on Trac wiki page commenting facility
by Niall Douglas 31 May '15

31 May '15

Something Robert raised during the meetings at C++ Now was why can't people comment on Boost's Trac wiki pages? The simple answer is because Trac doesn't allow it and hasn't got to implementing it in many years (http://trac.edgewall.org/ticket/11676) despite it being technically as simple as appending a ticket's comments to a wiki page, so I spent some time researching what options are available: 1. https://trac-hacks.org/wiki/WikiCommentsPlugin This works by inserting the comments directly into the article text. Pros: The comments are the document. This lets the page author fix the problem and delete the comment where that is appropriate. Cons: You need a trac login and editing privs to comment, which until a Trac 1.0 upgrade remains manually awarded by a Boost admin. No preview, so you need to know Trac wiki markup. 2. Disqus https://disqus.com/ This is the grand daddy of free commenting services. This works by you inserting some Javascript into the page where you want the comments to appear. AJAX does the rest. This could very easily patched into Trac for every wiki page by tweaking its template as per the instructions at http://trac.edgewall.org/wiki/TracInterfaceCustomization. Pros: Very well understood by users, in fact by everyone. Built in excellent spam protection. Nice UI. Just works. I also have a ton of ready to go infrastructure from nedprod.com for Disqus, so it's really very little effort for me to integrate this. Cons: They own all your data. They serve adverts in the comment stream, though apparently you can now opt out. They track user visits and sell the information, so AdBlock and Ghostery default block Disqus. Comment load times can be very slow. Comments aren't indexed by Google, and this may decrease the value of the system. 3. Keep looking Niall! Like none of the above? There are open source clones of Disqus you can host on your own infrastructure, but I have no experience with any of the those. If the community really doesn't like either of the two above, I guess I can keep looking. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

[locale] Build failure on develop
by Marcel Raad 30 May '15

30 May '15

Hi, since Tuesday, all Boost.Locale tests have been failing on all compilers: http://www.boost.org/development/tests/dev elop/developer/locale.html The MSVC results only mention an expected has_iconv.cpp build failure and it seems all other results only say "Error extracting file: No matching files were found." I tested on my local machine with MSVC 14 RC and the library wouldn't compile because of a missing "#include <map>": https://github.com/boostorg/locale/pull/8

1 0

[bind] Placeholders suggestion, std and boost
by Edward Diener 30 May '15

30 May '15

I realize that changing boost::bind so by default that placeholders of the form _n needing some sort of namespace in front of it will break plenty of code, so I am not suggesting doing that. What I would like to suggest is a Boost.bind macro, which when used before including <boost/bind>, would put the boost::bind placeholders of the form _n in a boost::placeholders namespace. The reason for this suggestion is so that boost::bind and std::bind can be similar syntactically enough so that one could choose one or the other depending on compiler support. Since in the C++ std the placeholders are in the std::placeholders namespace, having a means to have the boost::bind placeholders in the boost::placeholders namespace would be a means to that end.

5 16

[type_traits] Big changes in develop
by John Maddock 30 May '15

30 May '15

A heads up that the "Version2" rewrite of type traits is now in develop. There's still lots to do - more PR's will happen over the coming weeks to remove obsoleted code from other libraries (and quash the warnings that they'd otherwise generate). The docs also need a major update. In the mean time please do shout loudly if there are any regressions caused by this change. Thanks, John.

8 26

[test] Fwd: [Boost-testing] All test runners (windows and linux) crashing
by Rene Rivera 29 May '15

29 May '15

Boost Test developers please fix ASAP. ---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Thu, May 28, 2015 at 8:26 PM Subject: Re: [Boost-testing] All test runners (windows and linux) crashing To: Running Boost regression tests <boost-testing(a)lists.boost.org>, Boost Developers List <boost(a)lists.boost.org> On Thu, May 28, 2015 at 6:24 PM, Tom Kent <lists(a)teeks99.com> wrote: > All my test runners are quickly crashing during each run...here's the end > of the output in my results/bjam.log file: > > boost-test(RUN) "test/doc_boost_test_macro1" : > "libs/test/doc/examples/boost_test_macro1.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : > "libs/test/doc/examples/boost_test_macro2.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : > "libs/test/doc/examples/boost_test_macro3.cpp" > error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 > error: Unable to find file or target named > error: '../doc/examples/test_float_01.cpp' > error: referred to from project at > error: '../libs/test/test' > > Any thoughts? > Tom > I should have specified, that is on the develop branch. Master seems fine. _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

All test runners (windows and linux) crashing
by Tom Kent 29 May '15

29 May '15

All my test runners are quickly crashing during each run...here's the end of the output in my results/bjam.log file: boost-test(RUN) "test/doc_boost_test_macro1" : "libs/test/doc/examples/boost_test_macro1.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : "libs/test/doc/examples/boost_test_macro2.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : "libs/test/doc/examples/boost_test_macro3.cpp" error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 error: Unable to find file or target named error: '../doc/examples/test_float_01.cpp' error: referred to from project at error: '../libs/test/test' Any thoughts? Tom

1 1