May 2020 - Boost - lists.boost.org

[interprocess] Mutex and condition at process termination
by Phil Endecott 20 May '20

20 May '20

Dear Experts, Can we improve how interprocess mutexes and condition variables behave on process termination? Currently if a process terminates (i.e. it crashes, or you press ctrl-C), the interprocess docs say nothing as far as I can see about what happens to locked mutexes and awaited conditions. In practice it seems that mutexes that were locked remain locked, and other processes will deadlock. (I'm using Linux.) A few thoughts: * If a process were only reading the shared state, then it would be appropriate for the mutex to be unlocked on termination. * If a process were modifying the shared state, then it would be wrong to unconditionally unlock the mutex. So it would be useful to distinguish between reader and writer locks, even if we're not implementing a single-writer/multiple-reader mutex. * The system could be made more robust by blocking signals while a mutex is locked. This doesn't help with crashes, e.g. segfaults, but it would help with ctrl-C. * It may be useful to cause all processes to terminate if one of them terminates with a mutex held for writing, either immediately or as soon as they try to lock the same mutex. Perhaps also to delete the presumed-corrupted shared memory segment. * PTHREAD_MUTEX_ROBUST might be part of the solution. That seems to require the non-crashed process to do clean up, i.e. we would need to record whether the crashed process were reading or writing and react appropriately. I'm less clear about what happens to condition variables, but it does seem that perhaps terminating a process while it is waiting on a condition will cause other processes to deadlock. Perhaps the wait conceptually returns and the mutex is re-locked during termination. I have encountered this while trying to use a simple diagnostic program that just dumps some shared memory data structures and waits on a condition in a loop. I run this for a while and then press ctrl-C. Yes, a while after I disconnect the diagnostic program the system crashes... the worst sort of bug! Regards, Phil.

6 17

Embarcadero PRs
by Edward Diener 20 May '20

20 May '20

I have PRs for these libraries, which have passed CI testing, for distinguishing the Embarcadero C++ clang-based compilers from the legacy bcc32 compiler: beast thread regex container python program_options units circular_buffer graph parameter unordered random typeof Can the maintainers of these libraries please merge the appropriate PR ? The PR should not affect any other compiler, and it gives a chance for the Embarcadero C++ clang-based compiler(s) to use the appropriate Boost library even when some lacking feature or Embarcadero bug currently prevents the full functionality of the library to be used.

1 0

Re: [boost] [B2] Propagate CXX requirements to consumers
by Nikita Kniazev 19 May '20

19 May '20

> I guess this could be solved if B2 allows negation. So I can say: > `<target-os>not windows:<build>no `. > Does this exist? It is supported, but was broken until recently https://github.com/boostorg/build/pull/594

1 0

BOOST_NO_CXX11_HDR_CHRONO?
by Frédéric 19 May '20

19 May '20

Hi, When I compile the following program: #include <boost/math/constants/constants.hpp> #include <chrono> int main() { return 0; } with a osx cross compiler based on clang 9 on linux,I get the following warnings (full output below): CAUTION: This message was generated due to the define: BOOST_NO_CXX11_HDR_CHRONO [-W#pragma-messages] This is quite strange as the compiler generates the binary which means there was no issue to find <chrono>. What's wrong then? Kind regards, F $ x86_64-apple-darwin13-clang++-libc++ -o boost_math_constants -Wall -Wextra -std=c++14 -m64 -mmacosx-version-min=10.9 -I/softs/osx64-clang-9.0.1/release/boost/include boost_math_constants.cpp In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:99:1: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: One or more C++11 features were found to be unavailable") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:307:2: note: expanded from here message("CAUTION: One or more C++11 features were found to be unavailable") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:100:1: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021.") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:310:2: note: expanded from here message("CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021.") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:101:1: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message.") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:313:2: note: expanded from here message("CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message.") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:102:1: warning: CAUTION: This message was generated due to the define: BOOST_NO_CXX11_HDR_CHRONO [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: This message was generated due to the define: " BOOST_MATH_CXX03_WARN_REASON) ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:316:2: note: expanded from here message("CAUTION: This message was generated due to the define: " "BOOST_NO_CXX11_HDR_CHRONO") ^ 4 warnings generated.

5 15

[Config] Swappable/Movable std::streambuf requirement
by Alexander Grund 18 May '20

18 May '20

Hello, C++11 has `std::basic_streambuf<char>::swap` and move operators for that defined. However there are stdlibs which don't support that. clang 5.0 on travis e.g. fails due to that. Is there already something in Boost.Config dealing with that case which I can `requires` on to skip the build for that case? Most of the checks I've seen in Boost.Config are using the C++ feature test macros but for this there is none. If it doesn't exist: Would this be something to be added to Boost.Config? Or my local build files? How would such a test work? Can anyone point me to a similar example? I'm having trouble navigating over the many partially auto-generated files in Boost.Config. Thanks, Alex

2 2

Continued Fraction library/extension for Boost
by Fahad Syed 14 May '20

14 May '20

Hello, I am an Electrical Engineering fresher at National Institute of Technology, Srinagar. I have a proposal for a Continued Fraction class, with all arithmetic implemented through Gosper's HAKMEM algorithm. Here are some advantages/applications I can think of right now for a continued fraction representation: 1. Exact, base-independant representation of rationals AND irrationals (of course limited by the precision required) 2. Unlike rationals where numerator and denominator need to be "canonicalized" (i.e. divided by gcd for optimal representation), continued fraction arithmetic incorporates that naturally. 3. Approximation: Continued fraction give the best possible rational approximation for a given number 4. Comparison is extremely easy and fast 5. Conversion to float and base-conversion do not require division. Conversion to float, especially, is extremely fast and simple. I propose to implement most of the functions supported by the multi-precision library. Although I am sure there are many more applications and advantages, I would like some feedback on whether this library/extension would be of enough interest to be included in boost. Thank you.

1 0

[Filesystem] Directory entry caching
by Chris Glover 13 May '20

13 May '20

Hi All, Whatever happened to the work in this branch https://github.com/boostorg/filesystem/tree/feature/directory-entry-cache-r… that looks to implement this paper? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html Wondering if it's planned, dead, or looking for someone to do the work. I ran into the problem today by chance. -- chris

4 10

[Range] Transform in place
by Frederick Gotham 11 May '20

11 May '20

Earlier today I wrote the following two lines of code: auto const my_range = v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2); boost::range::transform( my_range, my_range.begin(), std::bit_not<uint8_t>() ); However it would have been nice as a one-liner: boost::range::transform( v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2), std::bit_not<uint8_t>() ); Why isn't there a form of "range::transform" that can transform in place (and therefore takes exactly two arguments)?

3 2

Boost.Asio's service_registry::do_use_service may block forever if a service with the same key was created
by Niklas Gürtler 11 May '20

11 May '20

Hello boost developers, I found a bug in Boost.Asio on Windows using IOCP that can make the service_registry::do_use_service block forever if a service with the same key was created and registered while the mutex was unlocked. If the service uses win_iocp_io_context, its destructor (implicitly called upon return, by destroying new_service) will join() the internal thread for IOCP handling, without requesting it to stop before. This will leave both threads to block forever, while the mutex_ is still locked (lock's destructor may be called after new_services), which may cause further blockages in other threads. I submitted a PR ( https://github.com/boostorg/asio/pull/350 ) which aims to fix this by calling shutdown() on the thread before returning, and unlocking the mutex explicitly before that. Another solution would be to call shutdown() from within win_iocp_io_context::~win_iocp_io_context(). Regards, Niklas Gürtler

1 0

Boost and unsigned chars
by REIX, Tony 11 May '20

11 May '20

Hi, I have tried to build Boost, and mainly Boost.math, with -funsigned-char, and I’ve faced several issues. Is Boost designed to work with unsigned chars (default on AIX) in addition to signed chars (default on Fedora)? Thanks Tony

1 0