asio-users Mailing List for asio C++ library
Brought to you by:
chris_kohlhoff
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(6) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(7) |
Nov
(8) |
Dec
(11) |
2006 |
Jan
(11) |
Feb
(14) |
Mar
(8) |
Apr
(3) |
May
(27) |
Jun
(15) |
Jul
(43) |
Aug
(64) |
Sep
(19) |
Oct
(44) |
Nov
(69) |
Dec
(82) |
2007 |
Jan
(79) |
Feb
(153) |
Mar
(169) |
Apr
(148) |
May
(181) |
Jun
(114) |
Jul
(152) |
Aug
(104) |
Sep
(77) |
Oct
(128) |
Nov
(185) |
Dec
(215) |
2008 |
Jan
(100) |
Feb
(116) |
Mar
(115) |
Apr
(74) |
May
(152) |
Jun
(107) |
Jul
(117) |
Aug
(115) |
Sep
(141) |
Oct
(75) |
Nov
(31) |
Dec
(47) |
2009 |
Jan
(51) |
Feb
(65) |
Mar
(54) |
Apr
(60) |
May
(6) |
Jun
(107) |
Jul
(82) |
Aug
(133) |
Sep
(144) |
Oct
(11) |
Nov
(54) |
Dec
(26) |
2010 |
Jan
(30) |
Feb
(17) |
Mar
(93) |
Apr
(47) |
May
(93) |
Jun
(73) |
Jul
(32) |
Aug
(60) |
Sep
(59) |
Oct
(58) |
Nov
(71) |
Dec
(28) |
2011 |
Jan
(58) |
Feb
(65) |
Mar
(38) |
Apr
(83) |
May
(45) |
Jun
(70) |
Jul
(71) |
Aug
(7) |
Sep
(33) |
Oct
(65) |
Nov
(33) |
Dec
(16) |
2012 |
Jan
(13) |
Feb
(32) |
Mar
(30) |
Apr
(67) |
May
(57) |
Jun
(59) |
Jul
(8) |
Aug
(61) |
Sep
(48) |
Oct
(23) |
Nov
(29) |
Dec
(8) |
2013 |
Jan
(37) |
Feb
(20) |
Mar
(11) |
Apr
(11) |
May
(9) |
Jun
(26) |
Jul
(6) |
Aug
(18) |
Sep
(7) |
Oct
(29) |
Nov
(2) |
Dec
(17) |
2014 |
Jan
(11) |
Feb
(12) |
Mar
(6) |
Apr
(26) |
May
(17) |
Jun
(12) |
Jul
(12) |
Aug
|
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(7) |
2015 |
Jan
(3) |
Feb
(3) |
Mar
(7) |
Apr
(23) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(33) |
Sep
(16) |
Oct
(2) |
Nov
(2) |
Dec
(13) |
2016 |
Jan
(7) |
Feb
(22) |
Mar
(11) |
Apr
|
May
(10) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
(29) |
Nov
(3) |
Dec
(21) |
2017 |
Jan
(4) |
Feb
(31) |
Mar
(8) |
Apr
(4) |
May
(1) |
Jun
(4) |
Jul
(32) |
Aug
(28) |
Sep
(2) |
Oct
(11) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
|
Nov
(4) |
Dec
(20) |
2019 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(11) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2023 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
(3) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Christian E. <CE...@gm...> - 2024-09-12 14:51:23
|
OS: linux-6.6.49 Boost: 1.84.0 I have taken an older "blocking read with timeout" example from here: https://lists.boost.org/Archives/boost/2007/04/120339.php This example (updated source code below) works fine as long as using the epoll reactor (simply try with a non connected UART, the program should finish after two seconds). But as soon as I switch to the io_uring implementation (by defining BOOST_ASIO_HAS_IO_URING and BOOST_ASIO_HAS_IO_URING_AS_DEFAULT), the 2nd timeout is not reached (program exits after 301 seconds). When I only define BOOST_ASIO_HAS_IO_URING (without BOOST_ASIO_HAS_IO_URING_AS_DEFAULT), the program works fine. Additionally I recognized that the behavior depends on the timing. When single stepping in a debugger, also the 2nd timeout works correctly. Q: Is the example program correct? Q: Why does it not work as expected with io_uring? regards, Christian #include <chrono> #include <iostream> #include <boost/asio.hpp> #include <boost/bind/bind.hpp> #include <boost/optional.hpp> #include <boost/system/error_code.hpp> using namespace boost; using namespace boost::asio; using namespace std::chrono; using namespace boost::placeholders; using namespace boost::system; void set_result(optional<boost::system::error_code>* a, boost::system::error_code b) { a->reset(b); } template <typename MutableBufferSequence> void read_with_timeout(io_context& io_context, serial_port& port, const MutableBufferSequence& buffers) { optional<error_code> timer_result; steady_timer timer(io_context); timer.expires_after(seconds(1)); timer.async_wait( boost::bind(set_result, &timer_result, _1)); optional<error_code> port_result; async_read(port, buffers, boost::bind(set_result, &port_result, _1)); io_context.restart(); while (io_context.run_one()) { if (timer_result) port.cancel(); else if (port_result) timer.cancel(); } if (port_result && *port_result) throw system_error(*port_result); } int main(int argc, char *argv[]) { io_context io_context; serial_port port(io_context, "/dev/ttymxc6"); char buf[4096]; try { std::cout << "Read (1) ...\n"; read_with_timeout(io_context, port, buffer(buf)); } catch (const std::exception& e) { std::cerr << "Exception: " << e.what() << '\n'; } try { std::cout << "Read (2) ...\n"; read_with_timeout(io_context, port, buffer(buf)); } catch (const std::exception& e) { std::cerr << "Exception: " << e.what() << '\n'; } } |
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-31 22:07:12
|
Em sáb., 31 de ago. de 2024 às 16:38, Vinnie Falco <vin...@gm...> escreveu: > On Sat, Aug 31, 2024 at 4:33 AM Vinícius dos Santos Oliveira > <vin...@gm...> wrote: > > Would this choice be acceptable for Lua bindings even if it deviates from the C++ API? > > In short, yes it is acceptable. Okay, I've also added bindings to Beast errors and released a new version. URL to the docs changed to <https://docs.emilua.org/beast/1.1/ref/beast.html>. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinnie F. <vin...@gm...> - 2024-08-31 19:37:27
|
On Sat, Aug 31, 2024 at 4:33 AM Vinícius dos Santos Oliveira <vin...@gm...> wrote: > Boost.Beast C++ API is different. Would this choice be acceptable for Lua bindings even if it deviates from the C++ API? In short, yes it is acceptable. Adding fields to a client handshake is a common operation, and there is no reason not to have this API. We could in theory add it to Beast, someone just needs to open an issue. However, your implementation is also OK. Thanks |
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-31 11:32:58
|
Here's what I had in mind for the client role: https://gitlab.com/emilua/beast/-/commit/4c7059cea27a65fbf302fa9a866932563a09de2f In retrospect, my previous email wasn't very clear in this part. So I decided to just commit some code to show what I had in mind. Now you can use Lua code such as the following to insert extra headers in the client handshake: ws:handshake(host, '/ws/api/v2', { origin = host }) Boost.Beast C++ API is different. Would this choice be acceptable for Lua bindings even if it deviates from the C++ API? That's what I was trying to ask. If it's okay, I can tag a new release with this code and release a new ArchLinux package. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-30 23:30:03
|
Em sex., 30 de ago. de 2024 às 19:24, Vinnie Falco <vin...@gm...> escreveu: > Would it help if Beast offered some new WebSocket APIs that create the > Upgrade response and return it to you? And we could add extra > websocket::stream APIs to perform the handshake assuming the caller > has already sent the upgrade response? Back at emilua-0.5 when WebSocket+HTTP were part of the core package, that's how I've designed the interface for extra headers: <https://docs.emilua.org/api/0.5/ref/websocket.html#new-websocket>. However back in 0.5, I wasn't really worried about following Boost.Beast conventions. This new plugin mirrors Boost.Beast interfaces very closely and so far, only existing Boost.Beast methods are exposed. For the extra headers, I can follow the same design (add an extra parameter for handshake() in the Lua interfaces to represent the HTTP extra request headers... and inject them in the C++-side through the decorator interface). Would you consider that acceptable for Lua bindings for Beast? Having the author's approval would give me confidence in this design and I'd be able to solve the client case today. The server role is not as urgent and could enjoy some more time on design iterations. I don't think creating the upgrade response and returning it would be the way to go in emilua. Emilua needs an embedded HTTP server (never in core though). If one is inspecting HTTP headers, I feel the way to go would be to have an actual HTTP server. Beast already has two interfaces for separate HTTP server implementations: * Passing headers extracted from the HTTP layer: https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/ref/boost__beast__websocket__stream/accept/overload5.html * Generating HTTP response headers: https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/using_websocket/decorator.html Likewise, Boost.Beast already provides an embedded HTTP server. So maybe offer it as well in this plugin. If anyone writes it, I can approve the PR. I can also give admin powers in this repo to someone affiliated with Boost.Beast. However, on my own time, I don't see myself writing bindings for Beast's HTTP abstractions. I plan on spending time to write a curl plugin as lots of folks will only ever trust curl to handle HTTP streams. Thoughts? -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinnie F. <vin...@gm...> - 2024-08-30 22:23:30
|
On Fri, Aug 30, 2024 at 2:46 PM Vinícius dos Santos Oliveira <vin...@gm...> wrote: ...you won't find beast::websocket::stream_base::decorator to change/examine HTTP fields. Would it help if Beast offered some new WebSocket APIs that create the Upgrade response and return it to you? And we could add extra websocket::stream APIs to perform the handshake assuming the caller has already sent the upgrade response? Thanks |
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-30 21:45:32
|
Last year I announced emilua here as Lua bindings for Boost.ASIO. Starting at version 0.6 at the beginning of this year, I've removed all HTTP/WebSocket classes from the core package as I've felt they don't belong in the core. Today I'm announcing emilua-beast 1.0 which is something I've hacked together over this week: https://docs.emilua.org/beast/1.0/ref/beast.websocket.html Code is available at <https://gitlab.com/emilua/beast>. This new plugin only exposes WebSocket abstractions. However I've spent a good time re-reviewing it several times to make sure it's usable in production (code quality wise). Basically everything exposed under boost::beast::websocket::stream is present here... except for callbacks. Lua has true coroutines which means suspending anywhere. C++ callback-based interfaces don't work well for emilua. Therefore you won't find beast::websocket::stream_base::decorator to change/examine HTTP fields. I'll have to think of a callback-less interface to interact with HTTP fields within WebSocket context as some HTTP fields such as origin and sec-websocket-protocol are too important to ignore (you'll be unable to connect to many public endpoint if you don't set these fields). Feedback welcome. I'll be using this plugin to write a nostr client which parsers multimedia content in secure sandboxes so it should see some real-world usage hopefully. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Li R. <lx...@ho...> - 2024-07-03 07:00:29
|
Hello list and Christopher I am a newbie to asio, and learning about it. I found many things in git repo didn’t match the document. That makes me very confused since I don’t have much confidence about my c++, thinking there are some magic behind it. Until now, two months later, I noticed the version in the git repo at sf are not the version the document were talking about. I would like to suggest submit a warning in the document that nobody download code from git in the first place. Sincerely Randy Sent from my iPad |
From: Vinícius d. S. O. <vin...@gm...> - 2024-04-04 12:30:43
|
The problem was partially fixed in commit https://github.com/chriskohlhoff/asio/commit/c0fbbddad10d342e9fbc6a7c13411ffedaf4bd31 However, that still causes problems for FreeBSD and other BSD systems. First, kqueue doesn't implement ioctls (FIONBIO is an ioctl), so you're still prevented from having a nested kqueue (through asio::posix::stream_descriptor) to use interfaces that are not exposed by Boost.Asio. One example of such interfaces not exposed by Boost.Asio is to await for a subprocess to finish. In FreeBSD, you have procdesc file descriptors returned by pdfork(). However you can't wait for readiness on this file descriptor. Instead, you have to watch for EVFILT_PROCDESC on kqueue: https://gitlab.com/emilua/emilua/-/blob/v0.6.0/src/freebsd/system/spawn.cpp#L111 (this code will consume 100% CPU on today's Boost.Asio because of the FIONBIO-on-the-nested-kqueue-fd bug). For other BSDs, you use NOTE_EXIT on an EVFILT_PROC instead of a EVFILT_PROCDESC to just stumble on the same Boost.Asio bug. For FreeBSD, a new workaround that is now possible due to this commit is to just call cap_ioctls_limit() on the nested kqueue file descriptor to force ENOTCAPABLE. Other BSDs can't use this workaround. I'll use this workaround in the future, but (1) other BSD systems are left to rot, and (2) this workaround doesn't solve all the problems. I don't even understand why Boost.Asio is setting non-blocking mode in a call to asio::posix::stream_descriptor::async_wait() to begin with. async_wait() is not the operation per se, but the event to wait for before doing the actual operation. Adding a fd on the set for readiness-waiting per se can't block, and neither FIONBIO nor fcntl makes any sense here. None of this current Boost.Asio behavior makes sense. Furthermore, Boost.Asio still is performing random ioctls for file descriptors that you might have received from untrusted processes. Most users won't care about it given most users control the origin of all file descriptors, but I have a project where this matters. Ideally I should be able to just disable this FIONBIO mess altogether and not worry about it ever again. And I'm still out-of-github. I asked a friend to submit a patch previously, but the patch was just ignored: https://github.com/chriskohlhoff/asio/pull/1406 (the second paragraph already explained problems not fixed in the commit that landed on the main repo, so I assume people only read the first paragraph and ignored everything else). It takes years to synchronize the supply chain across downstream distributors, so it's really frustrating to have a partially fixed patch when the original patch already fixed all the problems for the interested parties. Em qua., 6 de dez. de 2023 às 22:57, Vinícius dos Santos Oliveira <vin...@gm...> escreveu: > > I've been facing problems trying to use Github, so I can't report issues (nor send PRs) through Github. > > For now, I'll just report issues here in the list. > > In the last months I made extensive use of Boost.Asio on FreeBSD and I faced some problems. Almost all of them were related to indiscriminate usage of FIONBIO. By doing a quick search on Google I found out this ioctl() kinda predates POSIX and had inconsistent behaviour among different systems and even different objects in the same system. So it was a surprise to learn that Boost.Asio favours FIONBIO over fcntl(). > > A quick search for FIONBIO on ASIO's repo reveals it's not the first time this ioctl causes problems: https://github.com/chriskohlhoff/asio/commit/607f99ba80df71f1a96f0df71725059ee71e46ff > > For FreeBSD, the first problem I faced was related to Capsicum. Sending a Capsicum-protected file descriptor over an UNIX socket to a Boost.Asio process will block usage of ioctls on the file descriptor. The call for FIONBIO fails with ENOTCAPABLE and Boost.Asio refuses to work with the object for no good reason. > > The second problem I faced was trying to use posix::stream_descriptor to monitor a kqueue file descriptor. Boost.Asio doesn't try to support every feature the underlying system has so it offers some escape latches and posix::stream_descriptor is just one of these. However, posix::stream_descriptor will perform FIONBIO on the underlying descriptor (which of course isn't supported on kqueue file descriptors nor on many other file descriptors). This will cause async_wait() to fail. > > I think any usage of FIONBIO on Boost.Asio codebase should just be removed altogether. Recently ASIO started to require C++11 which is way way newer than fcntl() so it doesn't make sense to still depend on such problematic ioctl(). > > I have more issues to report (not all of them related to FreeBSD), but indiscriminate usage of ioctls (FIONBIO) is one that really bites my back and it's the only one I feel compelled to report sooner even if Github is playing games with me. > > > -- > Vinícius dos Santos Oliveira > https://vinipsmaker.github.io/ -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: <mat...@gm...> - 2024-02-12 16:11:31
|
Thanks Vinnie, I have considered that and unfortunately its not going to work for this application. I think I will need to backport some of the lib2 code. The biggest pieces I see are the newer code uses any_io_executor which if I'm understanding it, could be changed to use the older executor wrapper. Then there is the use of async_initiate. This one is not as clear to me but I think I can change it to async_result but need to look into it more. Thanks, Matt. On Fri, Feb 9, 2024 at 6:16 PM Vinnie Falco <vin...@gm...> wrote: > On Fri, Feb 9, 2024 at 2:51 PM <mat...@gm...> wrote: > >> I guess my question is about best practices for running both asio >> versions in the same application, in other words handling both >> io_context::run()? >> > > Well if you want to call `io_context::run()` you will need a separate > thread for each. I suspect this is not what you want, so instead you might > write: > > while( is_running() ) // your function > { > ctx0.run_for( std::chrono::milliseconds(50) ); > ctx1.run_for( std::chrono::milliseconds(50) ); > } > > You will need to figure out what works best for your application in terms > of dividing the time between the contexts. > > Thanks > > > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > _______________________________________________ > Using Asio? List your project at > http://think-async.com/Asio/WhoIsUsingAsio > |
From: Vinnie F. <vin...@gm...> - 2024-02-09 23:15:55
|
On Fri, Feb 9, 2024 at 2:51 PM <mat...@gm...> wrote: > I guess my question is about best practices for running both asio versions > in the same application, in other words handling both io_context::run()? > Well if you want to call `io_context::run()` you will need a separate thread for each. I suspect this is not what you want, so instead you might write: while( is_running() ) // your function { ctx0.run_for( std::chrono::milliseconds(50) ); ctx1.run_for( std::chrono::milliseconds(50) ); } You will need to figure out what works best for your application in terms of dividing the time between the contexts. Thanks |
From: <mat...@gm...> - 2024-02-09 22:50:18
|
Hi all, The ASIO website states that boost-asio and asio can coexist in the same application. I have a case where I need to do this. The application uses two libraries, lib1 and lib2. Lib1 uses asio version 1.12.0 and cannot be updated. Lib2 can use either asio or boost-asio but cannot use a version < 1.16.0 of asio. I guess my question is about best practices for running both asio versions in the same application, in other words handling both io_context::run()? Can anyone point me to an example of doing this? Thanks, Matt. |
From: Mark W. <mwi...@gm...> - 2023-12-28 19:55:41
|
Has anyone attempted to compile and run Boost ASIO on Green Hills Integrity OS? |
From: Vinícius d. S. O. <vin...@gm...> - 2023-12-07 02:27:23
|
On POSIX systems, asio::error::basic_errors will be just an alias for values that ASIO uses from std::system_category(). One of these is operation_not_supported (which is EOPNOTSUPP). However EOPNOTSUPP may alias ENOTSUP on some systems. For Linux and FreeBSD, these errno values are the same. For OpenBSD, macOS, and a few others they differ. When a composed operation throws ENOTSUP, the caller might accidentally catch EOPNOTSUPP on Linux or FreeBSD. There isn't really any good answer here. However I think Boost.Asio should just define asio::error::basic_errors::not_supported and document that not_supported and operation_not_supported might be aliases on some systems (they are on Linux and FreeBSD). That's what C++11 already does in a way by including both definitions so Boost.Asio could just follow along as well. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinícius d. S. O. <vin...@gm...> - 2023-12-07 01:57:37
|
I've been facing problems trying to use Github, so I can't report issues (nor send PRs) through Github. For now, I'll just report issues here in the list. In the last months I made extensive use of Boost.Asio on FreeBSD and I faced some problems. Almost all of them were related to indiscriminate usage of FIONBIO. By doing a quick search on Google I found out this ioctl() kinda predates POSIX and had inconsistent behaviour among different systems and even different objects in the same system. So it was a surprise to learn that Boost.Asio favours FIONBIO over fcntl(). A quick search for FIONBIO on ASIO's repo reveals it's not the first time this ioctl causes problems: https://github.com/chriskohlhoff/asio/commit/607f99ba80df71f1a96f0df71725059ee71e46ff For FreeBSD, the first problem I faced was related to Capsicum. Sending a Capsicum-protected file descriptor over an UNIX socket to a Boost.Asio process will block usage of ioctls on the file descriptor. The call for FIONBIO fails with ENOTCAPABLE and Boost.Asio refuses to work with the object for no good reason. The second problem I faced was trying to use posix::stream_descriptor to monitor a kqueue file descriptor. Boost.Asio doesn't try to support every feature the underlying system has so it offers some escape latches and posix::stream_descriptor is just one of these. However, posix::stream_descriptor will perform FIONBIO on the underlying descriptor (which of course isn't supported on kqueue file descriptors nor on many other file descriptors). This will cause async_wait() to fail. I think any usage of FIONBIO on Boost.Asio codebase should just be removed altogether. Recently ASIO started to require C++11 which is way way newer than fcntl() so it doesn't make sense to still depend on such problematic ioctl(). I have more issues to report (not all of them related to FreeBSD), but indiscriminate usage of ioctls (FIONBIO) is one that really bites my back and it's the only one I feel compelled to report sooner even if Github is playing games with me. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinícius d. S. O. <vin...@gm...> - 2023-12-06 09:32:39
|
Emilua was announced here a few months ago as an execution engine for Lua built on top of Boost.Asio. Now a new version has been released. The focus for this release was refactoring the internals so it'd be easier to build single-binary applications in the future. As an example of this work, now Emilua only ever queries the filesystem if nothing is found on the in-memory module cache. This allows you to pre-populate the module cache with all Lua files that make up your Lua program from main(). Future releases will improve this support even further by focusing on decreasing module cache populating time. So, what's in for C++ programmers? Not every piece of your C++ program is critical. For boring tasks where performance doesn't matter as much, you can just write it in Lua and enjoy a tight integration with asio::io_context so it communicates adequately with your C++ code. You can also set up some C++ routines to be called from Lua. There's a new tutorial on how to embed this runtime in your C++ programs: < https://docs.emilua.org/api/0.5/tutorial/embedding.html>. Aside from this work, there are a couple of big features in this release as well: - Support for Linux's Landlock. - Support for FreeBSD's Capsicum. These are the sandboxing technologies that better accommodate compartmentalised application development built around capabilities. The full changelog is available at < https://docs.emilua.org/api/0.5/changelog.html>. This is also the last version that's going to include builtin HTTP and WebSocket support. From 0.6 onwards you'll have to install a separate plugin to have access to these features. If you're writing libraries based on Boost.Asio, you might find it useful to write Lua bindings using Emilua. This would give you: - A test bench to quickly iterate over your high-level API by hiding unimportant boilerplate found on C++ and ASIO code. - A cleaner language to write unit tests with. - A larger public for your API (Lua users). I also found several bugs with Boost.Asio on FreeBSD while working on this release, but I'm struggling to report them using Github. I'm not sure how to proceed here. Is there an alternative way to send reports and pull requests w/o Github? -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Eduardo P. <edu...@gm...> - 2023-07-05 00:05:34
|
I am using asio and C++20 coroutines to wait for a socket to become ready for read or write. Please, see example below: asio::awaitable<void> waitForIO(asio::ip::tcp::socket& socket, asio::socket_base::wait_type waitType) { std::cout << "start waiting for " << (waitType ==asio::socket_base::wait_type::wait_write ? "write" : "read") << std::endl; // line 1 co_await socket.async_wait(waitType, use_awaitable); // line 2 std::cout << "socket became ready to " << (waitType ==asio::socket_base::wait_type::wait_write ? "write" : "read") << std::endl; // line 3 } void startIO() { std::cout << "spawning write coroutine" << std::endl; // line 4 asio::co_spawn(socket->get_executor(), waitForIO(socket, socket, asio::socket_base::wait_type::wait_write), asio::detached); // line 5 std::cout << "spawning read coroutine" << std::endl; // line 6 asio::co_spawn(socket->get_executor(), waitForIO(socket, asio::socket_base::wait_type::wait_read), asio::detached); // line 7 } Note: At the point where I am spawning the coroutines the respective io executor is already running. I assume I will always get the sequence (co_spawn immediately makes coroutine to execute line 2 - wait for read/write): 1. spawning write coroutine 2. start waiting for write 3. spawning read coroutine 4. start waiting for read I am wondering whether co_spawn can instead produce sequences like below: A - does not immediately start to wait for read or write: 1. spawning write coroutine 2. spawning read coroutine 3. start waiting for write 4. start waiting for read B - Becomes ready to write (or socket is cancelled) before waiting for read: 1. spawning write coroutine 2. spawning read coroutine 3. start waiting for write 4. socket became ready to write 5. start waiting for read Thanks, Eduardo Panisset. |
From: Vinícius d. S. O. <vin...@gm...> - 2023-04-03 16:25:12
|
Em seg., 3 de abr. de 2023 às 11:18, Vinnie Falco <vin...@gm...> escreveu: > I see you have deployed Antora :) > >From everything I've tried until this day, Antora is the best. However I personally prefer to use manpages. Manpages are much more distraction-free than any web-based documentation framework. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinnie F. <vin...@gm...> - 2023-04-03 14:17:24
|
On Mon, Apr 3, 2023 at 6:54 AM Vinícius dos Santos Oliveira <vin...@gm...> wrote: > Documentation: https://docs.emilua.org/api/0.4/ Interesting! I see you have deployed Antora :) Thanks |
From: Vinícius d. S. O. <vin...@gm...> - 2023-04-03 13:52:58
|
Hi list, I'd like to announce a project I've been working on for the past few years, and I think it finally reached a point where it may be generally useful for more people. Emilua brings Lua bindings for ASIO. Here are a few links for the project: - Repository: https://gitlab.com/emilua/emilua - Documentation: https://docs.emilua.org/api/0.4/ - Blog: https://blog.emilua.org/ - Homepage: https://emilua.org/ Initially I wanted a playground to experiment with async & concurrent IO for assorted reasons. Upon evaluating popular programming languages I came to the conclusion that Ruby and Lua would be good enough for the things I had in mind, and I decided to go with Lua. Some time later Ruby independently got better support for concurrent IO. Another similar project exists, but it's similar only in its dependencies (Boost.Asio), and nowhere near the capabilities I managed to achieve with Emilua: https://github.com/ignacio/LuaNode As a hint for what are such capabilities, newer Python releases failed to actually make good use of their subinterpreters: https://lwn.net/Articles/820424/ Python subinterpreters is an interesting idea, but few projects explore this kind of idea as far as I'm aware. Meanwhile Emilua not only allows you to spawn multiple Lua VMs to exploit Boost.Asio thread pools in a similar fashion to what Christopher Kohlhoff demoed with executors[1], but also allows you to spawn new Lua VMs isolated into Linux namespaces for sandboxing purposes (for the next versions I plan to support Landlock and Capsicum as well): https://docs.emilua.org/api/0.4/tutorial/linux_namespaces.html As for the implementation, a realization simplified the interface for Lua programs a lot. Much of Boost.Asio's complexity lies in emulating fibers on top of poor (but high-performance) language constructs. You create asynchronous agents to basically perform a sequential composition of asynchronous operations (as in... calling another function when the previous "returns"). Now, this could also be said to be poor promises/futures, but asynchronous agents also have associated characteristics (such as executors, allocators, and cancellation slots) that are closer to the fiber world. Some of these associated characteristics would be variables in the fiber stack, but in ASIO a convoluted vocabulary must be used to pass them around. Other associated characteristics would be implicit associated context to each fiber (e.g. cancellation slots). Therefore, for Emilua, I rely exclusively on (Lua) fibers to represent asynchronous agents. When you start a new asynchronous operation, the operation will preserve associated characteristics such as executors. Interrupting a fiber[2] causes the invocation of the cancellation slot's handler (that is transparently installed when a fiber initiates an asynchronous operation). In short, intent is captured out of the usage around fiber vocabulary, and that is translated to Boost.Asio patterns (e.g. remap-post-to-defer, work guards as required, ...). The interface for Lua programs is easy enough that you don't need an expert to make programs in it. The point is that you're using Lua to prototype things that don't require high-performance. Once the algorithm is in place, translation to Boost.Asio would be trivial (just add all the boilerplate code to implement protocols such as completion tokens, proper executors usage, etc). My stand is that the translation would be trivial because it's just boilerplate (mechanical work), and the Lua program will still use all the Boost.Asio concepts (you have sockets, acceptors, the interfaces are mostly the same...). And if you do not need performance for some module in your program, you could write only that part in Lua (the project license is very permissive, and in the future I intend to make embedding it in your own C++ project even easier). For the code that you do write in Lua, the runtime should never crash, and I've done my best to have as few bugs as possible. Boost.Asio flexible threading layout is retained in Emilua. The runtime starts with 1 asio::io_context / 1 thread. Calling spawn_context_threads() spawns more threads to the asio::io_context that manages the calling Lua VM. You may call spawn_vm() to spawn more Lua VMs. Each Lua VM is managed by its own strand. You can spawn more VMs to the same asio::io_context as the caller (the default), or you may spawn it in a new asio::io_context. You may even pass concurrency hints when spawning VMs in new asio::io_contexts. You may also configure threading layout when building the runtime so different algorithms (e.g. implicit strands) and defines (e.g. BOOST_ASIO_DISABLE_THREADS and BOOST_ASIO_CONCURRENCY_HINT_UNSAFE) are used. So, yeah, pretty much every threading layout made possible by Boost.Asio is also possible here. Furthermore, the API for communication among Lua VMs is influenced by the actor model. For a start, that means you may include the address of another actor in the message itself to allow arbitrary messaging topology. You can even spawn actors isolated through Linux namespaces to have a protection model similar to what FreeBSD's Capsicum project offers. The exception type used to communicate errors to Lua programs is basically a wrapper around std::error_code. You may even create your own error categories from Lua programs (the single-category-instance will be achieved by integrating Lua error categories with Lua modules as modules are also unique and global objects even when multiple Lua VMs exist). Portable error comparison through std::generic_category() is also available. You may even have localized error messages for your own categories. Emilua doesn't offer scatter-gather operations for Lua programs. If you do need scatter-gather operations, write a C++ plugin. Yes, there is support for native plugins through Boost.DLL. I even created a plugin to integrate Boost.Asio execution contexts with GTK+'s GLib event loops: https://gitlab.com/emilua/glib So it's possible to create Lua bindings for your own Asio-based libraries as well. For instance, bindings for Boost.Redis could be created as a separate plugin and used transparently by Lua programs. That is an opportunity for authors of Asio-based libraries to widen their audience. There's a pretty huge document detailing the internals of the project (more than what you want to know): https://docs.emilua.org/api/0.4/tutorial/internals.html Speaking of integration, as a side effect of this project, I end up reporting and fixing bugs in many open source projects[3][4][5][6][7] (including Boost.Asio itself). For the buffer type involved in IO operations, Emilua was heavily influenced by Golang's slices[8]: https://docs.emilua.org/api/0.4/ref/byte_span.html As in Boost.Asio, the proactor model is followed. A fiber blocks upon starting an asynchronous operation, and it'll stay blocked until the associated completion event is generated. Buffers involved in the operation need to stay alive until the completion event is received, but that's already guaranteed by the use of buffers inspired by Golang's slices. Many generic algorithms available in Boost.Asio are also available for Emilua, such as ip.connect(), stream.write_all(), stream.read_at_least(), and others. However, the use of fibers makes programming so convenient that one could just as easily implement them by hand if one really wants to. Fibers also give you vocabulary to deal with Boost.Asio's composed operations problems[9]: https://docs.emilua.org/api/0.4/tutorial/streams.html#composed-operations Bindings for APIs only available for certain operating systems also exist. For instance, on UNIX systems you may make use of setresuid(). On Windows, you may make use of TransmitFile(). Furthermore, optimizations specific for certain operating systems are also available even when Boost.Asio itself doesn't offer them yet (e.g. GetAddrInfoExW() will be used if you compile the project with _WIN32_WINNT >= 0x0602). Meson wrap system is used to make builds on Windows easier without impacting Linux builds[10]. Unfortunately most CI systems are disappointingly greedy w.r.t. Gitlab account permissions, so I don't enable them in the main repo and there will be no "passing/failing" badges that are so common nowadays. As for features, there are plenty. Here's a short list with extra stuff that I didn't mention above: - Usual Asio stuff: TCP, UDP, TLS, address/service forward/reverse name resolution, UNIX sockets, pipes, files, UNIX signals, clocks & timers, serial ports. - Extensions on top of Asio customization mechanisms (e.g. SCM_RIGHTS, TransmitFile(), SNI on TLS, Boost.Asio workarounds). - Stuff unrelated to Asio: filesystem, basic ctty/pty support & job control, JSON, HTTP, WebSocket, basic regex support. - A generic scanner to parse textual streams inspired by AWK. It's much more powerful than the asio::read_until() you're used to, but it still retains composability powers. - Documentation is not only available online, but it's also installable as manpages. The plan for the next release is to improve the module system and create a package manager. I experimented with guix in the past, but I've grown dissatisfied with it over time. [1] https://github.com/chriskohlhoff/executors/blob/master/src/examples/executor/actor.cpp [2] https://docs.emilua.org/api/0.4/tutorial/interruption.html [3] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1960 [4] https://github.com/shadow-maint/shadow/issues/635 [5] https://reviews.llvm.org/D105758 [6] https://github.com/skvadrik/re2c/issues/343 [7] https://lists.isocpp.org/std-proposals/2021/07/2809.php [8] https://go.dev/blog/slices-intro [9] https://sourceforge.net/p/asio/mailman/asio-users/thread/5357B16C.6070508%40mail1.stofanet.dk/ [10] https://brennan.io/2020/05/08/meson/ -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Marian K. <mkl...@gm...> - 2023-03-25 23:09:04
|
Done. https://github.com/chriskohlhoff/asio/pull/1267 On Sat, 25 Mar 2023 at 11:10, Vinícius dos Santos Oliveira <vin...@gm...> wrote: > > Em sáb., 25 de mar. de 2023 às 08:01, Marian Klein <mkl...@gm...> escreveu: >> >> Please , can you add to 1.82 ? > > > Open a PR against <https://github.com/chriskohlhoff/asio>. Every few weeks Chris looks into open PRs and batch-merges them without warning. You won't receive comments on your PR, but it doesn't mean it's ignored (you need to watch for recent commits on the git history to see if it was merged). > > Given you won't receive feedback, really take your time to make a very well polished PR with rationales and all, so you have a better chance of actually having the PR merged. > > > -- > Vinícius dos Santos Oliveira > https://vinipsmaker.github.io/ > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > _______________________________________________ > Using Asio? List your project at > http://think-async.com/Asio/WhoIsUsingAsio |
From: Vinícius d. S. O. <vin...@gm...> - 2023-03-25 11:09:39
|
Em sáb., 25 de mar. de 2023 às 08:01, Marian Klein <mkl...@gm...> escreveu: > Please , can you add to 1.82 ? > Open a PR against <https://github.com/chriskohlhoff/asio>. Every few weeks Chris looks into open PRs and batch-merges them without warning. You won't receive comments on your PR, but it doesn't mean it's ignored (you need to watch for recent commits on the git history to see if it was merged). Given you won't receive feedback, really take your time to make a very well polished PR with rationales and all, so you have a better chance of actually having the PR merged. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Marian K. <mkl...@gm...> - 2023-03-25 11:00:33
|
Yes, your suggestion would work but that would require changes at hundreds places in my application. Code should behave the same with no changes to the application. The next two exceptions for const_buffers_1 and mutable_buffers_1 should have been added in 1.80 boost in buffers.hpp I test const_buffers_1 case and it works for me. Please , can you add to 1.82 ? namespace boost { namespace asio { BOOST_ASIO_NODISCARD inline BOOST_ASIO_CONST_BUFFER buffer( const const_buffers_1& b, std::size_t max_size_in_bytes) BOOST_ASIO_NOEXCEPT { return buffer(static_cast<const const_buffer&>(b),max_size_in_bytes); } BOOST_ASIO_NODISCARD inline BOOST_ASIO_MUTABLE_BUFFER buffer( const mutable_buffers_1& b, std::size_t max_size_in_bytes) BOOST_ASIO_NOEXCEPT { return buffer(static_cast<const mutable_buffer&>(b),max_size_in_bytes); } } } On Sat, 25 Mar 2023 at 08:13, Allen <all...@gm...> wrote: > > Would your code work correctly on all versions of boost >= 1.66 (which added buffer.size) if you did this: > > size_t chunk_size=min(16, buf.size()); > auto buf2= boost::asio::buffer(buf.data(),chunk_size); > > Definitely frustrating to work around a breaking change, but better solution is to get your code working on all versions, IMO. > > (FYI, I am not affiliated with boost or asio projects.) > > On Sat, Mar 25, 2023, 12:06 AM Marian Klein <mkl...@gm...> wrote: >> >> Hey guys. >> >> This is my first message on this forum. >> I believed the project follows the principle: >> If the code compiles over the change it has to have the same or >> equivalent meaning at the runtime under any use (or none) of the >> pre-existing preprocessor definitions. >> It is better to break something at compile time over the change rather >> than wasting time debugging applications. Wasting 3 days to cluelessly >> debug an application is no fun. >> >> https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/history.html >> >> Asio 1.24.0 / Boost 1.80 >> "Added buffer() overloads for contiguous containers, such as std::span". >> >> Example: >> BOOST_ASIO_NO_DEPRECATED is undefined, I use (Visual Studio 2019, x86 >> build C++17 standard enabled) >> >> void broken(const boost::asio::const_buffer& data) >> { >> auto buf=boost::asio::buffer(data);//works in 1.79 and in 1.80.1.81, >> in all versions invokes/uses correctly boost/asio/buffer.hpp:942 >> //buf is const_buffers_1 type >> >> size_t chunk_size=16; >> auto buf2= boost::asio::buffer(buf,chunk_size); >> //for me it works in version 1.79 (intended behaviour getting left >> part of buffer of chunk_size), >> // the code compiles ,but it does not work the same in 1.80/1.81 >> //invokes boost/asio/buffer.hpp:954 in 1.79 correctly, but >> silently invokes/calls new code in boost/asio/buffer.hpp:1705 in >> 1.80/1.81 >> //with buf2 pointing to buff class , rather than its underlying data. >> >> //buf2 is const_buffers_1 type >> } >> >> You should have maintained original binding (as if const_buffer type) >> if the type is both (sequence of const_buffer of size 1) >> const_buffers_1 and (base class) const_buffer. >> And new changing behaviour must be requested explicitly with a new define >> BOOST_ASIO_BUFFERS_1_IS_BUFFER_SEQUENCE >> Can you rectify in 1.82 , please? >> Thank you. >> Best Regards >> >> boost/asio/buffer.hpp:954 : >> >> /// Create a new non-modifiable buffer from an existing buffer. >> /** >> * @returns A const_buffer value equivalent to: >> * @code const_buffer( >> * b.data(), >> * min(b.size(), max_size_in_bytes)); @endcode >> */ >> BOOST_ASIO_NODISCARD inline BOOST_ASIO_CONST_BUFFER buffer( >> const const_buffer& b, >> std::size_t max_size_in_bytes) BOOST_ASIO_NOEXCEPT >> { >> return BOOST_ASIO_CONST_BUFFER(b.data(), >> b.size() < max_size_in_bytes >> ? b.size() : max_size_in_bytes >> #if defined(BOOST_ASIO_ENABLE_BUFFER_DEBUGGING) >> , b.get_debug_check() >> #endif // BOOST_ASIO_ENABLE_BUFFER_DEBUGGING >> ); >> } >> >> >> >> boost/asio/buffer.hpp:1705: >> >> /// Create a new non-modifiable buffer from a contiguous container. >> /** >> * @returns A const_buffer value equivalent to: >> * @code const_buffer( >> * data.size() ? &data[0] : 0, >> * min( >> * data.size() * sizeof(typename T::value_type), >> * max_size_in_bytes)); @endcode >> */ >> template <typename T> >> BOOST_ASIO_NODISCARD inline BOOST_ASIO_CONST_BUFFER buffer( >> const T& data, std::size_t max_size_in_bytes, >> typename constraint< >> is_contiguous_iterator<typename T::const_iterator>::value, >> defaulted_constraint >> >::type = defaulted_constraint()) BOOST_ASIO_NOEXCEPT >> { >> return BOOST_ASIO_CONST_BUFFER( >> data.size() ? detail::to_address(data.begin()) : 0, >> data.size() * sizeof(typename T::value_type) < max_size_in_bytes >> ? data.size() * sizeof(typename T::value_type) : max_size_in_bytes); >> } >> >> >> _______________________________________________ >> asio-users mailing list >> asi...@li... >> https://lists.sourceforge.net/lists/listinfo/asio-users >> _______________________________________________ >> Using Asio? List your project at >> http://think-async.com/Asio/WhoIsUsingAsio > > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > _______________________________________________ > Using Asio? List your project at > http://think-async.com/Asio/WhoIsUsingAsio |
From: Allen <all...@gm...> - 2023-03-25 08:12:25
|
Would your code work correctly on all versions of boost >= 1.66 (which added buffer.size) if you did this: size_t chunk_size=min(16, buf.size()); auto buf2= boost::asio::buffer(buf.data(),chunk_size); Definitely frustrating to work around a breaking change, but better solution is to get your code working on all versions, IMO. (FYI, I am not affiliated with boost or asio projects.) On Sat, Mar 25, 2023, 12:06 AM Marian Klein <mkl...@gm...> wrote: > Hey guys. > > This is my first message on this forum. > I believed the project follows the principle: > If the code compiles over the change it has to have the same or > equivalent meaning at the runtime under any use (or none) of the > pre-existing preprocessor definitions. > It is better to break something at compile time over the change rather > than wasting time debugging applications. Wasting 3 days to cluelessly > debug an application is no fun. > > https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/history.html > > Asio 1.24.0 / Boost 1.80 > "Added buffer() overloads for contiguous containers, such as std::span". > > Example: > BOOST_ASIO_NO_DEPRECATED is undefined, I use (Visual Studio 2019, x86 > build C++17 standard enabled) > > void broken(const boost::asio::const_buffer& data) > { > auto buf=boost::asio::buffer(data);//works in 1.79 and in 1.80.1.81, > in all versions invokes/uses correctly boost/asio/buffer.hpp:942 > //buf is const_buffers_1 type > > size_t chunk_size=16; > auto buf2= boost::asio::buffer(buf,chunk_size); > //for me it works in version 1.79 (intended behaviour getting left > part of buffer of chunk_size), > // the code compiles ,but it does not work the same in 1.80/1.81 > //invokes boost/asio/buffer.hpp:954 in 1.79 correctly, but > silently invokes/calls new code in boost/asio/buffer.hpp:1705 in > 1.80/1.81 > //with buf2 pointing to buff class , rather than its underlying data. > > //buf2 is const_buffers_1 type > } > > You should have maintained original binding (as if const_buffer type) > if the type is both (sequence of const_buffer of size 1) > const_buffers_1 and (base class) const_buffer. > And new changing behaviour must be requested explicitly with a new define > BOOST_ASIO_BUFFERS_1_IS_BUFFER_SEQUENCE > Can you rectify in 1.82 , please? > Thank you. > Best Regards > > boost/asio/buffer.hpp:954 : > > /// Create a new non-modifiable buffer from an existing buffer. > /** > * @returns A const_buffer value equivalent to: > * @code const_buffer( > * b.data(), > * min(b.size(), max_size_in_bytes)); @endcode > */ > BOOST_ASIO_NODISCARD inline BOOST_ASIO_CONST_BUFFER buffer( > const const_buffer& b, > std::size_t max_size_in_bytes) BOOST_ASIO_NOEXCEPT > { > return BOOST_ASIO_CONST_BUFFER(b.data(), > b.size() < max_size_in_bytes > ? b.size() : max_size_in_bytes > #if defined(BOOST_ASIO_ENABLE_BUFFER_DEBUGGING) > , b.get_debug_check() > #endif // BOOST_ASIO_ENABLE_BUFFER_DEBUGGING > ); > } > > > > boost/asio/buffer.hpp:1705: > > /// Create a new non-modifiable buffer from a contiguous container. > /** > * @returns A const_buffer value equivalent to: > * @code const_buffer( > * data.size() ? &data[0] : 0, > * min( > * data.size() * sizeof(typename T::value_type), > * max_size_in_bytes)); @endcode > */ > template <typename T> > BOOST_ASIO_NODISCARD inline BOOST_ASIO_CONST_BUFFER buffer( > const T& data, std::size_t max_size_in_bytes, > typename constraint< > is_contiguous_iterator<typename T::const_iterator>::value, > defaulted_constraint > >::type = defaulted_constraint()) BOOST_ASIO_NOEXCEPT > { > return BOOST_ASIO_CONST_BUFFER( > data.size() ? detail::to_address(data.begin()) : 0, > data.size() * sizeof(typename T::value_type) < max_size_in_bytes > ? data.size() * sizeof(typename T::value_type) : max_size_in_bytes); > } > > > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > _______________________________________________ > Using Asio? List your project at > http://think-async.com/Asio/WhoIsUsingAsio > |
From: Marian K. <mkl...@gm...> - 2023-03-25 04:04:38
|
Hey guys. This is my first message on this forum. I believed the project follows the principle: If the code compiles over the change it has to have the same or equivalent meaning at the runtime under any use (or none) of the pre-existing preprocessor definitions. It is better to break something at compile time over the change rather than wasting time debugging applications. Wasting 3 days to cluelessly debug an application is no fun. https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/history.html Asio 1.24.0 / Boost 1.80 "Added buffer() overloads for contiguous containers, such as std::span". Example: BOOST_ASIO_NO_DEPRECATED is undefined, I use (Visual Studio 2019, x86 build C++17 standard enabled) void broken(const boost::asio::const_buffer& data) { auto buf=boost::asio::buffer(data);//works in 1.79 and in 1.80.1.81, in all versions invokes/uses correctly boost/asio/buffer.hpp:942 //buf is const_buffers_1 type size_t chunk_size=16; auto buf2= boost::asio::buffer(buf,chunk_size); //for me it works in version 1.79 (intended behaviour getting left part of buffer of chunk_size), // the code compiles ,but it does not work the same in 1.80/1.81 //invokes boost/asio/buffer.hpp:954 in 1.79 correctly, but silently invokes/calls new code in boost/asio/buffer.hpp:1705 in 1.80/1.81 //with buf2 pointing to buff class , rather than its underlying data. //buf2 is const_buffers_1 type } You should have maintained original binding (as if const_buffer type) if the type is both (sequence of const_buffer of size 1) const_buffers_1 and (base class) const_buffer. And new changing behaviour must be requested explicitly with a new define BOOST_ASIO_BUFFERS_1_IS_BUFFER_SEQUENCE Can you rectify in 1.82 , please? Thank you. Best Regards boost/asio/buffer.hpp:954 : /// Create a new non-modifiable buffer from an existing buffer. /** * @returns A const_buffer value equivalent to: * @code const_buffer( * b.data(), * min(b.size(), max_size_in_bytes)); @endcode */ BOOST_ASIO_NODISCARD inline BOOST_ASIO_CONST_BUFFER buffer( const const_buffer& b, std::size_t max_size_in_bytes) BOOST_ASIO_NOEXCEPT { return BOOST_ASIO_CONST_BUFFER(b.data(), b.size() < max_size_in_bytes ? b.size() : max_size_in_bytes #if defined(BOOST_ASIO_ENABLE_BUFFER_DEBUGGING) , b.get_debug_check() #endif // BOOST_ASIO_ENABLE_BUFFER_DEBUGGING ); } boost/asio/buffer.hpp:1705: /// Create a new non-modifiable buffer from a contiguous container. /** * @returns A const_buffer value equivalent to: * @code const_buffer( * data.size() ? &data[0] : 0, * min( * data.size() * sizeof(typename T::value_type), * max_size_in_bytes)); @endcode */ template <typename T> BOOST_ASIO_NODISCARD inline BOOST_ASIO_CONST_BUFFER buffer( const T& data, std::size_t max_size_in_bytes, typename constraint< is_contiguous_iterator<typename T::const_iterator>::value, defaulted_constraint >::type = defaulted_constraint()) BOOST_ASIO_NOEXCEPT { return BOOST_ASIO_CONST_BUFFER( data.size() ? detail::to_address(data.begin()) : 0, data.size() * sizeof(typename T::value_type) < max_size_in_bytes ? data.size() * sizeof(typename T::value_type) : max_size_in_bytes); } |