- Boost - lists.preview.boost.org

[LEAF] Loss of error_id
by Bjorn Reese 26 May '20

26 May '20

In the noexcept case, what happens in the Error-Handling function if the error_id generated by the Error-Reporting function is lost by the intermediate functions?

2 4

Request for 1.73 patch release
by Richard Hodges 25 May '20

25 May '20

Dear all, Just prior to the release of boost 1.73, some changes appeared in Asio which use the new c++20 concepts (and concepts-ts) features where available. These changes have introduced breakage in Beast in compilers where concepts are enabled. Examples are gcc=10 and clang10 with -std=c++20. I have pushed a fix to beast/develop to address this, but sadly we only became aware of the problem after the release of boost 1.73.0 I suspect the cause here is a combination of my relatively new appointment as a Beast maintainer and the ground-breaking event which I am sure c++20 will prove to be. I welcome any guidance on preparing or initiating a patch release as I lack the Arcane Knowledge required. For information, here is a link to the commit which fixes the problem: https://github.com/boostorg/beast/pull/1927 And some bug reports that alerted us that somethig was wrong: https://github.com/boostorg/beast/issues/1916 https://github.com/boostorg/beast/issues/1925 -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

6 13

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