- Boost - lists.boost.org

Re: [boost] [LEAF] The usage of TLS
by Bjorn Reese 22 May '20

22 May '20

On 2020-05-04 01:15, Andrzej Krzemienski via Boost wrote: > There is a number of reasons people do not want to or cannot use the C++ > exception handling mechanism. One of them is that the implementation of > exception handling requires the usage of TLS, and TLS is not implementable > on some platforms, like GPUs. If Nvidia's compiler does not implement C++ > exception handling mechanism, it is not because it would be slow, but > because it would require TLS support. From this perspective, if I cannot > use C++ exceptions because of TLS and I have to use something else, then > another TLS-based library is not really an alternative. In this case it > does not matter that it is only IDs that are stored in TLS. The sole fact > of even employing TLS is a deal breaker. LEAF really only needs one thread-local pointer to the topmost context per thread, so it may be possible to replace the thread-local storage with a global lock-free hash table. A lock-free hash table only requires atomic support, which is generally available on GPUs and microcontrollers. The key of the hash table could be the thread id. Task-based RTOS systems could use its task handle instead. An example of a lock-free hash table: https://eourcs.github.io/LockFreeCuckooHash/

2 1

Re: [boost] [container] Proposal for ring queues
by Bjorn Reese 22 May '20

22 May '20

On 2020-05-22 00:17, Andrey Semashev via Boost wrote: > I would like to ask if there is interest in the community for these > kinds of containers. I know I would find them useful, and at least one > person commented in the PR to the same effect. However, I would still > like to see if more people need this. Do notice that we also have this proposal floating around: https://lists.boost.org/Archives/boost/2019/09/246925.php https://lists.boost.org/Archives/boost/2020/05/248871.php

2 1

Help sought with identifying failure cases on the boost.org test matrix
by Richard Hodges 22 May '20

22 May '20

Dear all, Looking here: https://www.boost.org/development/tests/master/developer/beast.html We're seeing a lot of yellow, but when I run tests locally I get 100% passes. I'm reaching out to anyone who might have information on how I can replicate the steps to failure, and then either fix the problem or help the test host correct the configuration, as appropriate. Many thanks for your time. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

2 1

[Bimap] Maintenance
by Matias Capeletto 21 May '20

21 May '20

Hello Some Boost.Bimap's maintenance PRs have remained unmerged. The library also hasn't been following additions to the STL that should be mapped in the provided containers and implementing proper support for move semantics, between other features. Since I haven't been involved in C++ for a while, I am not currently in a position to push for a new version and I would prefer to allow other people to become a maintainer. What is the process to enable other maintainers to push the library forward? Best Matias

4 4

Review Wizard Status Report for May 2020
by Mateusz Loskot 20 May '20

20 May '20

============================================== Review Wizard Status Report for May 2020 ============================================== News ==== List of events that happened since the last report in 2016 is long and includes 13 releases of Boost, 21 libraries accepted and 4 libraries rejected. Details at https://www.boost.org/community/review_schedule.html What happened in 2020: 1. 2020-01: Ronald Garcia retired as a Review Wizard. Thank you Ronald! 2. 2020-02: StaticString accepted 3. 2020-04: Boost 1.73 Released New Libraries: - Nowide from Artyom Beilis, maintained by Alexander Grund - StaticString from Vinnie Falco and Krystian Stasiowski 4. 2020-05: Bimap library needs a maintainer https://lists.boost.org/Archives/boost/2020/05/248940.php Review Schedule Status ====================== The following libraries need a review manager: * JSON - author: Vinnie Falco, Krystian Stasiowski, Peter Dimov The following libraries have review managers, but have not yet been scheduled for review: * none The following libraries have review managers and have been scheduled for review: * LEAF - May 22, 2020 - May 31, 2020; author: Emil Dotchevski; review manager: Michael Caisse * Text - June 11, 2020 - June 20, 2020; author: Zach Laine; review manager: Glen Fernandes The following libraries have been reviewed and await reports from their review managers: * none The following libraries have been accepted to Boost, but have not yet been integrated into Boost Git: * Double-Ended - conditionally accepted in October 2017; author: Benedek Thaler * Parallel Sorting Sub-library - accepted November 2016; author: Francisco José Tapia The following libraries have been accepted and submitted to Boost Git, but have not yet appeared in a release: * STLInterfaces - conditionally accepted December 2019; author: Zach Laine The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * STLInterfaces - conditionally accepted December 2019; author: Zach Laine General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email us at Mateusz Loskot (mateusz at loskot dot net) or John Phillips (johnphillipsithaca at gmail dot com). We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Mateusz. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[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