October 2016 - Boost-users - lists.preview.boost.org

R: Re: [ASIO] Do coroutines allow serving multiple clients at once?
by mmarkd9＠libero.it 10 Oct '16

10 Oct '16

Thanks, does spawning a coroutine also spawn a new thread? I'd be inclined to think so from what you told me ----Messaggio originale---- Da: "Oliver Kowalke" <oliver.kowalke(a)gmail.com> Data: 10-ott-2016 15.19 A: "boost-users"<boost-users(a)lists.boost.org> Ogg: Re: [Boost-users] [ASIO] Do coroutines allow serving multiple clients at once? 2016-10-10 9:44 GMT+02:00 mmarkd9(a)libero.it <mmarkd9(a)libero.it>: I'd like to know if this code is able to serve multiple clients connecting at the same time to the server. I would say no. You spawn only one coroutine that calls in the for-loop async. operations of accept(), read() and write() in a sequence. No other client is able to connect to your server, e.g. connect() on the client side returns, until you enter accept() again. In order to serve multiple clients at the same time you need to spawn a coroutine that accepts new connections and for each client request (read()/write() operations) you need to spawn a new coroutine.

1 0

Re: [Boost-users] [ASIO] Do coroutines allow serving multiple clients at once?
by mmarkd9＠libero.it 10 Oct '16

10 Oct '16

Thanks, does spawning a coroutine also spawn a new thread? I'd be inclined to think so from what you told me

1 0

[Boost.Filesystem] crashes in static destruction of global string object
by Nguyen Huu Hai 10 Oct '16

10 Oct '16

Hello, libs/filesytem/src/portability.cpp defines valid_posix as a std::string object instead of a const char * pointer. May I know if there are reasons for that? I'm using Boost.Filesystem as a shared library and my processes crash on exit with stack traces pointing to the static destruction of valid_posix. Making it const char* fixes the crashes. Regards, Hai

2 2

[ASIO] Do coroutines allow serving multiple clients at once?
by mmarkd9＠libero.it 10 Oct '16

10 Oct '16

I'm using ASIO with coroutines2 to create a ssl echo server. The code I've been experimenting is the following: http://nopaste.linux-dev.org/?1120051 While this is highly readable compared to the asynchronous callbacks version (thanks coroutines), I'd like to know if this code is able to serve multiple clients connecting at the same time to the server. In theory, every time I return control to the io_service object (i.e. I yield in the spawn coroutine) it should take care of whatever connection is pending / buffered / scheduled to be accepted next, right? Is this a reliable way to handle multiple requests? I don't plan on supporting massive workloads (e.g. 500k connections at once) but having some resilience would be nice indeed. Any other thoughts/tips are also warmly welcome.

2 1

Epoch to date
by Philippe de Rochambeau 09 Oct '16

09 Oct '16

Hello, how do you convert an Unix epoch (e.g., 1476015285) to a formatted date string (e.g., 1984-01-01) with Boost? Many thanks. Philippe

2 1

BoostLog and BoostASIO don't seem to play nice together
by james 08 Oct '16

08 Oct '16

Hi, I'm facing pretty much the same issue as was reported here in 2014: http://boost.2283326.n4.nabble.com/Boostlog-and-ASIO-crash-in-shared-librar… In short, I have a .so that wraps BoostASIO to create a HTTP client. Loading this .so into a program that also uses BoostLog results in either a segfault or no callbacks being fired (even async_resolve which I believe should eventually time-out). Removing all uses of and linking to BoostLog in the main program makes it all work again. Before I try to produce a minimum example, is this a known issue? Code is built with BOOST_LOG_DYN_LINK, asio is header only. We're using boost 1.55, and g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 Thanks James

1 0

graph strongly connected components
by Mika S 07 Oct '16

07 Oct '16

I am trying to use the implementation for strongly connected components http://www.boost.org/doc/libs/1_61_0/libs/graph/doc/strong_components.html Is this the iterative or the recursive implementation of tarjan's algorithm ?

2 2

GCC 5.3.0 failing Features Check when building Boost
by Carlos Ferreira 06 Oct '16

06 Oct '16

Hello I'm having some issues regarding the features check, when build Boost using OpenWRT GCC 5.3.0 cross-compiler for armv7. I'm building against musl. I have passed -std=c++14 to the cxxflags, but it seems to have no effect. This is the features output > - 32-bit : yes > - arm : yes > - symlinks supported : yes > - C++11 mutex : yes > - lockfree boost::atomic_flag : no > - Boost.Config Feature Check: cxx11_auto_declarations : no > - Boost.Config Feature Check: cxx11_constexpr : no > - Boost.Config Feature Check: cxx11_defaulted_functions : no > - Boost.Config Feature Check: cxx11_final : no > - Boost.Config Feature Check: cxx11_hdr_tuple : no > - Boost.Config Feature Check: cxx11_lambdas : no > - Boost.Config Feature Check: cxx11_noexcept : no > - Boost.Config Feature Check: cxx11_nullptr : no > - Boost.Config Feature Check: cxx11_rvalue_references : no > - Boost.Config Feature Check: cxx11_template_aliases : no > - Boost.Config Feature Check: cxx11_thread_local : no > - Boost.Config Feature Check: cxx11_variadic_templates : no > - has_icu builds : no > warning: Graph library does not contain MPI-based parallel components. > note: to enable them, add "using mpi ;" to your user-config.jam > - zlib : yes > - iconv (libc) : no > - iconv (separate) : yes > - icu : no > - icu (lib64) : no > - native-atomic-int32-supported : yes > - pthread-supports-robust-mutexes : yes > - compiler-supports-visibility : yes > - gcc visibility : yes > - long double support : yes > - zlib : yes What am I missing, so that all those cxx_* features can be checked? -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf(a)av.it.pt Skype & GTalk -> carlosmf.pt(a)gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

1 1

[regex] link error on upgrade to 1.62.0
by James Walker 05 Oct '16

05 Oct '16

Hi, I'm trying to update from 1.60.0 to 1.62.0 on Mac with Xcode 4.6.3, and I'm getting link errors on Regex. I am definitely compiling all 17 of the .cpp files in libs/regex/src. The errors are shown below. Any idea what I might be missing? Undefined symbols for architecture i386: "boost::re_detail_106200::perl_matcher<char const*, std::allocator<boost::sub_match<char const*> >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)", referenced from: boost::re_detail_106200::perl_matcher<char const*, std::allocator<boost::sub_match<char const*> >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(char const*, char const*, boost::match_results<char const*, std::allocator<boost::sub_match<char const*> > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, char const*) in BVHJointMap.o boost::re_detail_106200::perl_matcher<char const*, std::allocator<boost::sub_match<char const*> >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(char const*, char const*, boost::match_results<char const*, std::allocator<boost::sub_match<char const*> > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, char const*) in AnimationsManager.o "boost::re_detail_106200::perl_matcher<char const*, std::allocator<boost::sub_match<char const*> >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::find()", referenced from: bool boost::regex_search<char const*, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >(char const*, char const*, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags) in BVHJointMap.o "boost::re_detail_106200::perl_matcher<char const*, std::allocator<boost::sub_match<char const*> >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match()", referenced from: bool boost::regex_match<char const*, std::allocator<boost::sub_match<char const*> >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >(char const*, char const*, boost::match_results<char const*, std::allocator<boost::sub_match<char const*> > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags) in AnimationsManager.o ld: symbol(s) not found for architecture i386

1 1

boost::asio cross-library link issue
by Stanley Friesen 05 Oct '16

05 Oct '16

We are using Boost 1.54. The issue i have is a strange problem with the ASIO library. We have two libraries build using ASIO from Boost 1.54 (libpcl and one of our own libraries). For some reason, despite being built with the same version of boost, the layout of class task_io_service differs between the two libraries. The member function instantiations are in the libraries as weak symbols, so we do not get a link error, but which version of each function that is called from any given place is unpredictable, and varies when we change out own code. In particular, at least op_queue_ and all following members have offsets that differ by 8 bytes (the size of a 64-bit pointer) between the two builds. The result is that sometimes the op_queue back pointer is corrupted (by the other version setting stopped_), or the stop flag is not seen because it was set by the other build. The result is either that run() returns immediately without doing anything, or out application crashes from trying to dereference an invalid pointer. (Often what is supposed to be a NULL back pointer is set to 1, which does not compare equal to NULL). I have looked for conditionally compiled elements in task_io_service, op_queue, and epoll_reactor with no luck. I can see no reason the two library builds should end up with different class layouts. So, does anybody have any clue what might be happening here? Or how to go about fixing the problem? [I hesitate to try forcing strong symbols in our library, since this would break libpcl, due to many functions being inline]. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-asio-cross-library-link-issue-tp46… Sent from the Boost - Users mailing list archive at Nabble.com.

5 8