- Boost - lists.preview.boost.org

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 27 Dec '16

27 Dec '16

OK, thank you - I'll test your suggestions. Am 27.12.2016 2:12 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 12:45, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hello Daniel, > I'm referring to > http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/ fiber/performance.html > . > The page should contain three tables (the one related to threads is > missing) - my modification s date from end of November. > Oliver The change you referred to before was from the 17th, but the html file in git was last updated on the 10th. https://github.com/boostorg/fiber/blob/master/doc/html/ fiber/performance.html I guess that's what you're seeing. I'm not sure how the build is set up now, but I'm guessing it wasn't set up to build the fiber documentation because there's already html files there. To build the documentation, I think you need to change the end of your documentation jamfile to something like: alias boostdoc ; explicit boostdoc ; alias boostrelease : fiber ; explicit boostrelease ; Although, I can't test that now, so it might be wrong. I'd also delete the html documentation from the repo, as a broken link is a better indicator that the documentation isn't being built. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

1 0

Boost Fiber & ASIO CPU spinning
by Daniel Larimer 27 Dec '16

27 Dec '16

I am attempting to combine Boost Fiber with Boost ASIO and am having very poor results. Code: int main() { boost::asio::io_service io; boost::fibers::use_scheduling_algorithm< boost::fibers::asio::round_robin > ( io ); io.run(); return 0; } This code should startup and then sleep, but instead it pegs the CPU at 100%. The code I used for boost::fibers::asio::round_robin can be found here: http://www.boost.org/doc/libs/1_62_0/libs/fiber/examples/asio/round_robin.h… When I inspect the round_robin scheduler it appears to be switching back and forth between two different fibers. If I put a print statement inside asio_rr_service_lambda then it constantly reports that it has ready fibers. I'm looking for a working example. Dan

2 1

PHP error in string_ref docs
by Olaf van der Spek 27 Dec '16

27 Dec '16

Hi, Got a PHP error in the docs.. http://www.boost.org/doc/libs/master/libs/utility/doc/html/string_ref.html /home/www/live.boost.org/common/code/boost.php:16: htmlentities(): Invalid multibyte sequence in argument -- Olaf

2 3

Re: [boost] [stacktrace] review (changing vote to NO)
by Artyom Beilis 26 Dec '16

26 Dec '16

> > 1. use of -rdynamic/-export-dynamic should be noted in "bold face" regarding > > the use of the library. > > Those flags are not required because addr2line can extract information > from debug sections of the binary. Yes.. this is exactly the issue - I don't think that addr2line should be used by default. Getting the stack trace using dladdr works very well - so no need to use add2line unless absolutely required. I also want to hear regarding inefficiency of add2line use - creating the process for each stack frame you wanted to trace. It is very inefficient so I suggest not to use one. Finally reviewing your code once again I realized following: 1. Instead of using adde2line to get the object name you can just call add2line with /proc/12345/exe (works with dynamically loaded shared objects as well - i tested it) 2. Use of addr2line for every each frame must be fixed But what is most important that I understood that you don't even use dladdr to get function names even if you can - which is very bad decision. Additionally I realized that with_trace and traced aren't parts of the library! These should be built in there by default. -------------------------- After using the library and running couple of tests on Linux with GCC.. I have to revoke my "Conditional YES" vote and change it to "NO": And the reason is following: 1. Linux/*nix backend is poor - instead of using dladdr to get function names easily as I do in the backend I written and use on CppCMS [1] you call external exe in very inefficient way. 2. I realized that the library does not provide the basic functionality like collecting strack trace on throw (what I thought was built in but I was mistaken) 3. No answer for non MSVC compilers built in. But the most important reason that the library does not feel mature enough in terms of both backends and frontends. I strongly strongly strongly recommend to continue the work on the library as it provides important functionality. The frontend should be adjusted a little to couple with common cases. The backend must be modified to not to fork/exec by default and optimize one significantly. I clearly understand you to want to use addr2line as it gives more power but it can't be used by default. I searched for a long time for a lightweight solution for converting addresses to the function names for CppCMS including trying to use debug information but couldn't find anything suitable besides dlfunc. However addr2line is by no means can be accepted as "default" solution. I also recommend to take a look on cppcms's backtrace library it is very simple and provides critical information in production environment. Regards, Artyom Beilis [1] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/lib… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

6 11

[root_ptr] Potential support from Qt & QtQuickCompiler
by Phil Bouchard 25 Dec '16

25 Dec '16

Greetings, As you know the WebKit project has a very complex memory manager that cannot be swapped easily but The Qt Project might be interested for a faster alternative than the garbage collector: http://lists.qt-project.org/pipermail/development/2016-December/028199.html This is just a head's up in case anybody is interested into the subject and is aware of Qt. I know by experience garbage collectors will always let you down for complex projects so I think there is no other solution. Thanks & Merry Christmas, -Phil

1 0

Boost 1.63.0 Release Candidate 2
by Marshall Clow 25 Dec '16

25 Dec '16

The second release candidate for the 1.63.0 release is now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The only changes are in Boost.Config, Boost.Context, and Boost.Fiber. The SHA256 checksums are as follows: 25db3956a8d58187ac7a0702cc917e9bab47ff90baafc35e4e789dca1ce5f423 boost_1_63_0_rc2.7z beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 boost_1_63_0_rc2.tar.bz2 fe34a4e119798e10b8cc9e565b3b0284e9fd3977ec8a1b19586ad1dec397088b boost_1_63_0_rc2.tar.gz 97ce6635df1f44653a597343cd5757bb8b6b992beb3720f5fc761e3644bcbe7b boost_1_63_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

5 6

Re: [boost] Boost 1.63.0 Release Candidate 2
by Stephan T. Lavavej 24 Dec '16

24 Dec '16

[Marshall Clow] > The second release candidate for the 1.63.0 release is now available at: > https://sourceforge.net/projects/boost/files/boost/1.63.0/ > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. 1.63.0 RC2 successfully built for mingw-w64, without any workarounds. (Boost.Fiber is detecting my lack of std::mutex and simply not building, which is fine by me.) Notably, this is the first time that I've ever been able to build Boost without patches or workarounds. This is after bootstrap.sh was fixed for mingw-w64/msys2, Context/Coroutine/Coroutine2 were fixed to build for mingw-w64, and Python auto-detection started working again. Yay! Thanks, STL

2 1

Stacktrace review: concern, probable solution and review news
by Antony Polukhin 23 Dec '16

23 Dec '16

Hi, The biggest concern with the stacktrace library is it's usability in async-signal-handlers. Here are some facts: * users definitely want to use the library in async-signal-handlers to print stacktraces on SIGSEGV/SIGBUS/SIGABRT * the only cross-platform async-signal-safe thing that can be done - is to print function addresses (without names and source line locations) * reviewers wish to have a smaller size of the `stacktrace` class, want to avoid template parameter and have a std::vector<frames> like interface (this is async unsafe because vector does dynamic allocations). So, the solution: * Change `basic_stacktrace<size_t>` to `basic_stacktrace<class Allocator = std::allocator<void*>>` and make it's constructor async-unsafe and add additional runtime parameter for stack depth. * Provide async-safe functions that dump addresses separated by whitespace (format also acceptable by addr2line and atos): * `void dump_stacktrace(int fd)` * `void dump_stacktrace(HANDLE fd)` * `void dump_stacktrace(const char* filename)` * Provide an example with dumping callstack to a file and printing it on program restart Does it seem reasonable? Does it satisfy your needs? Review news: * User named LogicalKnight tested the library on MacOS and it works well. A few issues in examples must be fixed: https://github.com/apolukhin/stacktrace/issues/10 My list of TODOs for the library: * Fix the async unsafe code in signal catching example * ? Provide a low-level API for getting stacktrace as array of void pointers * MinGW fails to compile, because of missing "Dbgeng.h" headers. This must be fixed by manyally forward declaring required functions using the boost.winapi way. * Add a note about the Boost.Exception usage to the example with embedding stack into exception. * Take a look at the llvm-symbolizer, atos and libdwraf; try hard to produce a non-forking solution * ? Deserialization/inspection of stacktrace on other machine * BOOST_NOINLINE inline trick to avoid printing internals in the stacktrace + fix Intel warnings * At github one of the users was complaining about the performance of ostreaming operations. There is a way to significantly speedup ostreaming without changing the interface of the library. I'll do the optimization after the Boost Review. * Improve docs for the "Build, Macros and Backends" sections (say that library is using system headers, no 3rd party libraries must be installed or manually linked; backtrace() is LINUX specific, not POSIX) * Add a note to the docs that library is header only by default and usable in C++98/C++03. Things NOT to do ever: * Integration with BOOST_THROW_EXCEPTION and Boost.Exception - those ideas are out of the library scope * Callbacks to do things on stacktraces - no way to satisfy all the needs and make them optimal on all the platforms. Do some caching instead -- Best regards, Antony Polukhin

5 11

Re: [boost] [Stacktrace] review
by Barrett Adair 23 Dec '16

23 Dec '16

On Wed, Dec 14, 2016 at 2:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > The formal review of the Stacktrace library by Antony Polukhin starts > today 14th Dec and will conclude before Christmas. I appreciate we > are likely a bit tired out from the many library reviews recently and > of course it's Christmas, but given the lack of a portable way to > work with stack backtraces, which you inevitably need to do > eventually in any non-toy production application, Stacktrace needs > your review! > > For your review you may wish to consider the following questions: > > What is your evaluation of the design? I like it. > What is your evaluation of the implementation? I've never implemented a stacktrace reader, so I don't have much to add. The code did not raise any red flags for me, though. > What is your evaluation of the documentation? Documentation is solid. > What is your evaluation of the potential usefulness of the library? Very useful. I will likely use this at work. > Did you try to use the library? With what compiler? Did you have any problems? Yes, GCC 5.3, no problems. This stacktrace made me smile: 0# boost::stacktrace::detail::backend::backend(void**, unsigned long) 1# s::~s() 2# void __gnu_cxx::new_allocator<s>::destroy<s>(s*) 3# void std::allocator_traits<std::allocator<s> >::destroy<s>(std::allocator<s>&, s*) 4# std::_Sp_counted_ptr_inplace<s, std::allocator<s>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() 5# std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() 6# std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() 7# std::__shared_ptr<s, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() 8# std::shared_ptr<s>::~shared_ptr() 9# hello()::{lambda()#1}::~hello() 10# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_destroy(std::_Any_data&, std::integral_constant<bool, false>) 11# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_manager(std::_Any_data&, std::_Function_base::_Base_manager<hello()::{lambda()#1}> const&, std::_Manager_operation) 12# std::_Function_base::~_Function_base() 13# std::function<void ()>::~function() 14# void std::_Destroy<std::function<void ()> >(std::function<void ()>*) 15# void std::_Destroy_aux<false>::__destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 16# void std::_Destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 17# void std::_Destroy<std::function<void ()>*, std::function<void ()> >(std::function<void ()>*, std::function<void ()>*, std::allocator<std::function<void ()> >&) 18# std::vector<std::function<void ()>, std::allocator<std::function<void ()> > >::~vector() 19# hello() 20# main 21# __libc_start_main 22# _start > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 45 minutes total. I skimmed the code, the documentation, and the test cases. Then, I made a little test program. > Are you knowledgeable about the problem domain? No. > Do you think the library should be accepted as a Boost library? Yes, unequivocally. The concerns about async safety are interesting, but ultimately this library is useful to me (and likely many others) regardless of signal support. Barrett

1 0

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Remi Chateauneu 22 Dec '16

22 Dec '16

Maybe the RDTSC instruction might help for x86 processors, as it returns a number of ticks which is reset at startup. It is also extremely fast. Le 22 déc. 2016 13:04, "Thomas Dahms" <thomas.dahms(a)native-instruments.de> a écrit : Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 1