asio-users Mailing List for asio C++ library (Page 2)
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
|
Oct
|
Nov
|
Dec
|
From: Virgilio F. <vir...@gm...> - 2023-01-14 17:25:45
|
I finished the first version of the patch. It's able to send and receive 1 million packet / second on my box at same time (an intel i9 9900k / ubuntu 22.04 lts low latency kernel) using packet sizes of 64 / 1430 bytes without packet loss (using 64mb udp socket buffers) A little running demo is able to being watched at https://www.youtube.com/watch?v=Q3hqe6ntM3w Need to write some automatic tests for (async_)[send/receive]_multiple_buffer_sequence calls[_to/_from] and push a pure ASIO example in examples repository The working code is pushed on my github repository. On Tue, Jan 10, 2023 at 5:27 PM Virgilio Fornazin < vir...@gm...> wrote: > I'm finalizing writing a patch that enables sendmmsg / recvmmsg on > supported operating systems (Linux, [Free/Net/Open]BDS, AIX, Blackberry QNX > Neutrino). > > The syscalls are implemented in reactive_socket_service backend only (the > io_uring backend on Linux does not support sendmmsg / recvmmsg yet). > > The config.hpp has macros for forcible disable those calls, and detect > supported operating system compiler macros. > > New methods were developed for (send/send_to/receive/receive_from) > suffixed with '_multiple_buffer_sequence' that accepts a > multiple_buffer_sequence class (backed by > asio::detail::array<multiple_buffer_sequence_op, N> or > std::vector<multiple_buffer_sequence_op>) and a > multiple_buffer_sequence_adapter that convert ops to struct mmsghdr* for > sendmmsg/recvmmsg. > > The multiple_buffer_sequence implementations are basically a collection > of multiple_buffer_sequence_op instances that represents each socket > operation . > > <code> > buffer_sequence_type buffer_sequence_; > buffer_sequence_adapter_type buffer_sequence_adapter_; > endpoint_type endpoint_; > bool completed_; > socket_base::message_flags flags_; > std::size_t bytes_transferred_; > asio::error_code error_code_; > </code> > > The multiple_buffer_sequence implementations has full container support, > iterators, and support Mutable and Const buffer sequences. > > The patch is near a first working version (need to finalize work on > handlers yet), but I made the code available for review, scrutiny and > suggestions. > > The source code is in my github repo ( > https://github.com/virgiliofornazin/asio), > on branch feature/multiple_datagram_buffers_sequence-io-sendmmsg-recvmmsg > > ( full URL: > https://github.com/chriskohlhoff/asio/compare/master...virgiliofornazin:asio:feature/multiple_datagram_buffers_sequence-io-sendmmsg-recvmmsg > ) > > |
From: Virgilio F. <vir...@gm...> - 2023-01-10 20:27:57
|
I'm finalizing writing a patch that enables sendmmsg / recvmmsg on supported operating systems (Linux, [Free/Net/Open]BDS, AIX, Blackberry QNX Neutrino). The syscalls are implemented in reactive_socket_service backend only (the io_uring backend on Linux does not support sendmmsg / recvmmsg yet). The config.hpp has macros for forcible disable those calls, and detect supported operating system compiler macros. New methods were developed for (send/send_to/receive/receive_from) suffixed with '_multiple_buffer_sequence' that accepts a multiple_buffer_sequence class (backed by asio::detail::array<multiple_buffer_sequence_op, N> or std::vector<multiple_buffer_sequence_op>) and a multiple_buffer_sequence_adapter that convert ops to struct mmsghdr* for sendmmsg/recvmmsg. The multiple_buffer_sequence implementations are basically a collection of multiple_buffer_sequence_op instances that represents each socket operation . <code> buffer_sequence_type buffer_sequence_; buffer_sequence_adapter_type buffer_sequence_adapter_; endpoint_type endpoint_; bool completed_; socket_base::message_flags flags_; std::size_t bytes_transferred_; asio::error_code error_code_; </code> The multiple_buffer_sequence implementations has full container support, iterators, and support Mutable and Const buffer sequences. The patch is near a first working version (need to finalize work on handlers yet), but I made the code available for review, scrutiny and suggestions. The source code is in my github repo ( https://github.com/virgiliofornazin/asio), on branch feature/multiple_datagram_buffers_sequence-io-sendmmsg-recvmmsg ( full URL: https://github.com/chriskohlhoff/asio/compare/master...virgiliofornazin:asio:feature/multiple_datagram_buffers_sequence-io-sendmmsg-recvmmsg ) |
From: Poul B. <pou...@gm...> - 2022-11-20 17:09:13
|
Hi The following fascinating code will compile fine (and likely work as expected) on boost 1.80 however it wont' compile on 1.81 B1? The use case is being able to return some value from a coroutine. Thanks #include<boost/asio.hpp> #include<boost/asio/experimental/coro.hpp> #include<boost/asio/experimental/use_coro.hpp> usingnamespaceboost::asio; experimental::coro<int> my_coroutine(ip::tcp::socketmy_socket) { chardata[100]; std::size_tn= co_awaitmy_socket.async_read_some(buffer(data), experimental::use_coro); co_yieldn; } |
From: eugeny g. <jo...@dr...> - 2022-10-24 17:13:58
|
Hi, the code #if defined(ASIO_HAS_IOCP) void select_reactor::run_thread() { asio::detail::mutex::scoped_lock lock(mutex_); while (!stop_thread_) { lock.unlock(); op_queue<operation> ops; run(true, ops); scheduler_.post_deferred_completions(ops); lock.lock(); } } is to be at least void select_reactor::run_thread() { asio::detail::mutex::scoped_lock lock(mutex_); while (!stop_thread_) { lock.unlock(); op_queue<operation> ops; run(1, ops); scheduler_.post_deferred_completions(ops); lock.lock(); } } yep, it’s just cosmetic changing. but there we have a big problem - the thread will wake up every 1ms (mks?) and consume the CPU time in the usually empty loop. -- Yours sincerely, Eugeny. +33 6 38 52 27 93 |
From: Kasper L. <la...@st...> - 2022-06-21 16:39:46
|
On 21/06/2022 17.12, Sorin Cernescu wrote: > I'm using openssl 1.0.1e-fips. > I imagine sslv23 is till supported there (will check). > No matter if it's supported or not you definitely shouldn't be using SSL in any version. Why not just change your code to use TLS v1.2+? > It is strange that same library.method can be called with dlopen from > the same machine, but fails when loading the library from 3rd party app > (Siebel CRM). > My guess was that it might be using different versions/configurations of OpenSSL. I still have no idea if that is the actual cause of the error. Just trying to help with something that might be worth looking into. > => it is possiblle that process (from Siebel) to also use ssl and hence > the possible issue? > I have no idea what Siebel CRM is and from a quick search it seems like I should be quite happy to keep it that way. To be honest I don't think I can provide much more help. Also, this is probably not really related to Asio. Hope you'll resolve your issue. Kind regards, Kasper Laudrup |
From: Sorin C. <cns...@ya...> - 2022-06-21 15:12:17
|
Hello Kasper, Thanks for your reply. I'm using openssl 1.0.1e-fips. I imagine sslv23 is till supported there (will check). It is strange that same library.method can be called with dlopen from the same machine, but fails when loading the library from 3rd party app (Siebel CRM). => it is possiblle that process (from Siebel) to also use ssl and hence the possible issue? Thanks On Tuesday, June 21, 2022, 01:59:06 PM GMT+3, Kasper Laudrup <la...@st...> wrote: On 21/06/2022 12.34, Sorin Cernescu via asio-users wrote: > Hello, > > I designed a shared library(boost 1.78 , g++ 4.8.5) containing a method like this: > void f() > { > try > { > boost::asio::ssl::context ctx(boost::asio::ssl::context::sslv23); > } > catch(std::exception& e) > { > cout<<"exception depicted as: "<<e.what(); > } > cout<<"OKAY"; > } > > Then I test my library from the same machine in two different ways: > > a) It works ok when calling this method from a cprogram with dlopen() ( output: "OKAY") > b) From a custome application, if I load this library and then I call the same method, I have this output "exception depicted as: context: asio.ssl error [asio.ssl:336539714]" > > Any thought, please? > Some thoughts that haven't really been well investigated. OpenSSL error codes (which is what asio.ssl errors really are) can be quite tricky to deal with. It can sometimes be helpful to use the OpenSSL command line tool with the errstr command. There isn't a corresponding error string for 336539714, but converting it to hex gives: ❯ openssl errstr 140f3042 error:140F3042:SSL routines:func(243):called a function you should not call Which sounds more reasonable but still not very helpful. Then I noticed you are attempting to use sslv23. SSL in general is deprecated and version 2.3 of SSL is very deprecated which sounds like it might fit with the error string. Are you simply trying to use SSL v2.3 with a version of OpenSSL that has deprecated/disabled that protocol (as it should be)? Hope that helps a bit. Kind regards, Kasper Laudrup |
From: Kasper L. <la...@st...> - 2022-06-21 11:16:44
|
On 21/06/2022 12.34, Sorin Cernescu via asio-users wrote: > Hello, > > I designed a shared library(boost 1.78 , g++ 4.8.5) containing a method like this: > void f() > { > try > { > boost::asio::ssl::context ctx(boost::asio::ssl::context::sslv23); > } > catch(std::exception& e) > { > cout<<"exception depicted as: "<<e.what(); > } > cout<<"OKAY"; > } > > Then I test my library from the same machine in two different ways: > > a) It works ok when calling this method from a cprogram with dlopen() ( output: "OKAY") > b) From a custome application, if I load this library and then I call the same method, I have this output "exception depicted as: context: asio.ssl error [asio.ssl:336539714]" > > Any thought, please? > Some thoughts that haven't really been well investigated. OpenSSL error codes (which is what asio.ssl errors really are) can be quite tricky to deal with. It can sometimes be helpful to use the OpenSSL command line tool with the errstr command. There isn't a corresponding error string for 336539714, but converting it to hex gives: ❯ openssl errstr 140f3042 error:140F3042:SSL routines:func(243):called a function you should not call Which sounds more reasonable but still not very helpful. Then I noticed you are attempting to use sslv23. SSL in general is deprecated and version 2.3 of SSL is very deprecated which sounds like it might fit with the error string. Are you simply trying to use SSL v2.3 with a version of OpenSSL that has deprecated/disabled that protocol (as it should be)? Hope that helps a bit. Kind regards, Kasper Laudrup |
From: Sorin C. <cns...@ya...> - 2022-06-21 10:34:40
|
Hello, I designed a shared library(boost 1.78 , g++ 4.8.5) containing a method like this: void f() { try { boost::asio::ssl::context ctx(boost::asio::ssl::context::sslv23); } catch(std::exception& e) { cout<<"exception depicted as: "<<e.what(); } cout<<"OKAY"; } Then I test my library from the same machine in two different ways: a) It works ok when calling this method from a cprogram with dlopen() ( output: "OKAY") b) From a custome application, if I load this library and then I call the same method, I have this output "exception depicted as: context: asio.ssl error [asio.ssl:336539714]" Any thought, please? Regards, |
From: Vinnie F. <vin...@gm...> - 2022-02-22 03:17:46
|
On Mon, Feb 21, 2022 at 4:54 PM Rory Jaffe <rs...@gm...> wrote: > At each class's shutdown, I want to make sure the work is completed before destroying the class. You have it backwards. Instead of doing funny business in your workers' destructors, just make sure that the lifetime of the worker is extended until it is complete. In other words, in your worker class T, extend the lifetime by storing an instance of shared_ptr<T> in every completion handler associated with that worker. > Currently, I use a std::binary_semaphore, acquire the semaphore > when work first starts, then release the semaphore when the work > cycle exits, whether it exits by a socket error, finish signal, or exception. > Then I acquire the semaphore in the destructor, which forces the > destructor to wait for the semaphore to be released. Yeah this is going to be messy, as you have discovered. You should not need any additional synchronization primitives at all. If you find that you are trying to do "interesting" things in destructors of objects that perform work submitted to executors, it usually means you're using the wrong pattern. The usage of shared_ptr to manage the lifetime of long-running work is covered in my video "Get Rich Quick!", cued to the right time at this link: <https://youtu.be/7FQwAjELMek?t=1347> Once you invert the model of ownership as I described above, cleanly terminating the application becomes easy: 1. Stop queuing new work, and 2. Wait for io_context::run to return from all threads Hope this helps! |
From: Rory J. <rs...@gm...> - 2022-02-22 00:53:45
|
I found this old thread that asked a similar question, but wanted to bring it up again: https://sourceforge.net/p/asio/mailman/message/24964454/ In my application, there is a single io_context set up that has two threads, and is held open by adding another executor by: asio::any_io_executor work_ {asio::require(io_context_.get_executor(), asio::execution::outstanding_work.tracked)}; Then, in individual classes, I use asio::make_strand to derive individual strands from the single io_context, and work gets assigned through the strands. At each class's shutdown, I want to make sure the work is completed before destroying the class. Currently, I use a std::binary_semaphore, acquire the semaphore when work first starts, then release the semaphore when the work cycle exits, whether it exits by a socket error, finish signal, or exception. Then I acquire the semaphore in the destructor, which forces the destructor to wait for the semaphore to be released. The main application is responsible for terminating work_ and the io_context, which occurs after the individual classes destroy themselves. This works fine, but is messy and requires careful analysis of the code to make sure I acquire and release the semaphore correctly in all possible sequences of events. It would be much easier to set up a wait on all work done by the thread, but I do not see a way to do so. Is there some method of setting up a wait that I'm not aware of? |
From: <kevin.sullivan1@L3Harris.com> - 2021-12-31 16:32:13
|
I'm not sure who governs the think-async.com documentation pages, but upon using the non-boost/asio tutorial I've noticed the non-boost/asio tutorial includes Timer.3 - Binding arguments to a handler<https://think-async.com/Asio/asio-1.20.0/doc/asio/tutorial/tuttimer3.html?force_isolation=true> which needs a boost include file and hence uses boost::bind functionality. Timer 4 & 5 do as well. Might want to remove these from the non-boost/asio tutorial. Or skip them if you're using this tutorial. Daytime.1 uses boost::array as well, but apparently you can substitute char [] or std::vector for this (haven't tried this yet personally). Kevin J Sullivan Software Engineer, Software Engineering Acara Solutions / L3HARRIS TECHNOLOGIES t +1 856 338 3168 c 856 371 8516 L3Harris.com / Kevin.Sullivan1@L3Harris.com<mailto:Kevin.Sullivan1@L3Harris.com> 1 Federal Street / Camden, NJ, 08103 / USA CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving. |
From: Alex S. <ast...@bl...> - 2021-09-14 17:10:33
|
Hello, By default on QNX OS the select_reactor class is used, which uses the POSIX select() to wait for I/O and write to a pipe to interrupt the wait. Neither select() nor pipes are efficient on QNX OS. We propose to introduce new ionotify_reactor class for QNX OS, which uses ionotify() and pulses instead of select() and pipes. If you are interested in this patch please let me know how to proceed with it: - what repo and branch should we use for this patch? - what is mandatory test set should be done for this patch? - what documentation should be updated to reflect this patch? Thanks, Alex Steshkin ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
From: Vinnie F. <vin...@gm...> - 2021-05-27 15:53:24
|
On Thu, May 27, 2021 at 8:38 AM Trey Weaver <tre...@jp...> wrote: > Will asio support boost/beast/websocket in the future? No > Is it possible to add just the boost/beast/websocket to asio’s includes? This is not possible. ASIO is a low-level system library while Beast is mid-level protocol library. Thanks |
From: Trey W. <tre...@jp...> - 2021-05-27 15:37:18
|
Will asio support boost/beast/websocket in the future? Is it possible to add just the boost/beast/websocket to asio's includes? |
From: Игорь <tri...@ma...> - 2021-03-11 08:56:54
|
Hi, Once I encountered an ASIO_ASSERT "iterator out of bounds" in Asio buffers_iterator.hpp, here: https://github.com/chriskohlhoff/asio/blob/eb61fc9b9393aca436f1d22fd82823dca3753859/asio/include/asi o/buffers_iterator.hpp#L411 Is it a bug in Asio? What steps should I do to figure out the core of the problem? -- Igor |
From: Groke, P. <pau...@dy...> - 2021-02-02 15:08:17
|
Hi, I already asked this on the Boost developer mailing list - but I guess that was the wrong place to ask. So I'm cross-posting it here. Sorry for that. (We're using Boost.Asio but the code in question is the same in both, so I guess it doesn't matter.) I've noticed that ASIO's tss_ptr implementation doesn't use __declspec(thread) on Windows, except when compiling for WinRT. Instead it uses the win_tss_ptr implementation - which will cause a crash when there's no free TLS index. (There are static tss_ptr instances and loading a DLL where a ctor of a static variables throws a C++ exception seems to cause a crash -- no surprise there). AFAIK using implicit TLS via __declspec(thread) should fix this so that loading a DLL either works or fails gracefully. One problem that I know of with implicit TLS is that it fails catastrophically on Windows versions before Vista. Since WinRT wasn't available on pre-Vista versions, this might be a reason to restrict it to WinRT. But I don't know if there are/were other reasons to restrict use of implicit TLS to WinRT. So... is there another reason? If there's no other reason, that would be great, because we don't have to support pre-Vista versions. Meaning we could simply patch ASIO to use implicit TLS for MSVC in general. Regards, Paul Groke The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20 |
From: lampahome <pah...@mi...> - 2020-09-01 10:30:30
|
> > > I want to do is like libaio in unix system and want to find some library > to reach that easier. > > Hmm, I'm on linux and yet I find libasio works quite well for me. Maybe I > missed something. Although libasio gives me a bit more support, I think, > than just libaio's completion handlers. > I will try libasio and thanks your help > I have two threads(or one is main thread) and one thread will submit io of > file as more as it can, and another one thread will check the execution > state(i.e. return code) of each io. I thought this design pattern will > improve my program. > > I'd use completion handlers for checking return codes. Here's a snippet > from a function of mine, in case it can help: > > void TcpConnection::SendMessage(...) { > > boost::asio::async_write( > *sockets_[connection_index], > boost::asio::buffer(send_queue_[connection_index].front()), > [this, connection_index](boost::system::error_code ec, size_t > length) { > LOGGABLE; > // This is the completion handler. > if (ec) { > LOG_WARNING << "Failed to send message: " << AsioError(ec); > SendFailure(connection_index, ec); > return; > } > // ... > > > I forgot which handler can use lambda function. Thank you again. I will continue combine your advise and look up Doc to develope. |
From: Jeff A. <je...@p2...> - 2020-09-01 09:58:03
|
On 01/09/2020 11:46, lampahome wrote: > >> 2. If io_service.run() failed, is there any queue to let me know >> which job failed? Or it only jump exception? > > What do you mean by failed? The io_service probably didn't fail, > it's some task you asked it to do that failed. In that case, you > probably meant to catch the failure yourself. I.e., instead of > your task being > > My mistake. I mean the io operation failed. It seems read/write > handler can handle failed situations, but is there a centralized > queue(? or something) can collect these failed or all operations? The way I do this is that I call the dispatch functions with closures, so the function executing has the state it needs to do whatever it's going to do. And when I call a function with a completion handler, I again provide a closure so that it can do what it needs to do. One of the things a completion handler can do is check the result code of the operation. Now, I'll only class myself as "somewhere between newbie and expert but at neither extreme", so it's possible this conversation will uncover some problem with my error handling. > I want to do is like libaio in unix system and want to find some > library to reach that easier. Hmm, I'm on linux and yet I find libasio works quite well for me. Maybe I missed something. Although libasio gives me a bit more support, I think, than just libaio's completion handlers. > I have two threads(or one is main thread) and one thread will submit > io of file as more as it can, and another one thread will check the > execution state(i.e. return code) of each io. I thought this design > pattern will improve my program. I'd use completion handlers for checking return codes. Here's a snippet from a function of mine, in case it can help: void TcpConnection::SendMessage(...) { boost::asio::async_write( *sockets_[connection_index], boost::asio::buffer(send_queue_[connection_index].front()), [this, connection_index](boost::system::error_code ec, size_t length) { LOGGABLE; // This is the completion handler. if (ec) { LOG_WARNING << "Failed to send message: " << AsioError(ec); SendFailure(connection_index, ec); return; } // ... -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 http://p27.eu/jeff/ http://transport-nantes.com/ |
From: lampahome <pah...@mi...> - 2020-09-01 09:46:36
|
> > > program event-based or is it just that you have one file operation that > needs to be async? > My program is event-based 2. If io_service.run() failed, is there any queue to let me know which job > failed? Or it only jump exception? > > What do you mean by failed? The io_service probably didn't fail, it's > some task you asked it to do that failed. In that case, you probably meant > to catch the failure yourself. I.e., instead of your task being > My mistake. I mean the io operation failed. It seems read/write handler can handle failed situations, but is there a centralized queue(? or something) can collect these failed or all operations? I want to do is like libaio in unix system and want to find some library to reach that easier. I have two threads(or one is main thread) and one thread will submit io of file as more as it can, and another one thread will check the execution state(i.e. return code) of each io. I thought this design pattern will improve my program. Looks like the io_context, async_read, and async_write will help me, but the handler in Doc seems naive? void handle_write_error(const boost::system::error_code& ec, std::size_t){...} Every document told above handler, but it seems can only two arguments? Maybe some misunderstand, thank u. |
From: Jeff A. <je...@p2...> - 2020-09-01 09:26:43
|
On 01/09/2020 09:43, lampahome wrote: > Hi, all > I'm a rookie to boost.asio. > > I write a program to write files asynchronously by boost.asio. But I'm > confused with some point. You're not alone. Even with the docs, the learning curve is steep at first. > 1. I need to add job to boost::asio::io_service and call > io_service.run(), then it will start running all jobs. Is there any > function automatically running newly jobs after I add job? It's hard to answer without knowing what you want to do. The service needs to believe it has a reason to live (jobs queued), otherwise it will quit. For example, you can use functions like io_service.post() to ask a different service to do something (e.g., you have two threads and one wants the other to do something). Or if you have only one thread (main), you can push some task that never finishes until its good and ready and then let your whole program happen in that loop. As long as it's event-based, it will work out. Is your program event-based or is it just that you have one file operation that needs to be async? > 2. If io_service.run() failed, is there any queue to let me know which > job failed? Or it only jump exception? What do you mean by failed? The io_service probably didn't fail, it's some task you asked it to do that failed. In that case, you probably meant to catch the failure yourself. I.e., instead of your task being DoWork() maybe you meant to write try { DoWork } catch(const std::exception& e) { std::err << "Well, that didn't go very well." << std::end; } -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 http://p27.eu/jeff/ http://transport-nantes.com/ |
From: Arvid N. <arv...@gm...> - 2020-09-01 08:51:01
|
It appears that boost-1.74 does not accept a std::bind() expression as a valid handler. It used to, in previous versions. The error is (what appears to be) a SFINAE failure because whatever bind object is returned by std::bind() is not considered a valid receiver. It seems likely this was introduced in the work to conform with P0443. I had to make the following changes to make my code build with boost-1.74 https://github.com/arvidn/libtorrent/pull/5057/files#diff-8775d2d9460d9b7a42d64f06511742d7L2743 -- Arvid Norberg |
From: lampahome <pah...@mi...> - 2020-09-01 08:35:46
|
Hi, all I'm a rookie to boost.asio. I write a program to write files asynchronously by boost.asio. But I'm confused with some point. 1. I need to add job to boost::asio::io_service and call io_service.run(), then it will start running all jobs. Is there any function automatically running newly jobs after I add job? 2. If io_service.run() failed, is there any queue to let me know which job failed? Or it only jump exception? thanks |
From: Kasper L. <la...@st...> - 2020-08-11 19:42:49
|
Hi Scott, On 21/07/2020 21.53, Scott Mueller wrote: > > The Schannel methods are transport agnostic, so it should be possible to use these in ASIO just like OpenSSL. The only real gotchas in Schannel involve making certain that the use patterns are correct- the buffer set-up, renegotiation and shutdown are all handled properly. There is documentation for these, but it is tricky to navigate and the samples are strange (everything is under the same SSPI umbrella). Microsoft documentation in this arena is very sparse and only really makes sense if you are referring to a working sample. > As I wrote to Vinnie I have made proof-of-concept where I try to do that: https://github.com/laudrup/boost-asio-windows-sspi As I've had the misfortune to work with the Win32 API before I'm sort of used to the pain so I had to cross reference quite a few examples and code snippets I could find just to make this ugly POC work. > If you can find the Windows 2000 SDK, you'll find some complete (more or less) samples that implement an Schannel client and server. I've worked with this quite a bit in the past, so I could probably help with this some, time permitting. > It would most likely be very useful to get your input on some of the many quirks of using SChannel as I don't have any experience with that myself. Currently, I think I'll try to focus on trying to get a working design and leave handling of the strangeness until that is more or less in place. Thanks a lot and kind regards, Kasper Laudrup |
From: Kasper L. <la...@st...> - 2020-08-11 19:34:37
|
On 21/07/2020 22.45, Vinnie Falco wrote: > > Buffer-oriented ("bring your own socket") would be the most > straightforward, and also the area in which my colleagues and I have > the most experience. We can collaborate in the free C++ Language Slack > Workspace (get the invite at https://cppalliance.org/slack). > > And we can help with setting up a GitHub repository for CI and testing > workflow - the benefit of setting up a public repository early is that > stakeholders can look at code and comment on it, submit reviews, even > contribute by writing tests or example programs. > Sorry for taking so long to reply, but I have spent the time I had available on creating a very basic proof-of-concept using Windows SSPI/SChannel with boost::asio on Windows: https://github.com/laudrup/boost-asio-windows-sspi There are tons of things missing. I am not even able to create a TLS connection to boost.org unless I provide a hostname for validation to SSPI/SChannel (which is not currently possible in this implementation), but I think it works pretty well as a proof-of-concept. There are also many things wrong with the code that I'm fully aware of, but as you suggested Vinnie, I think I'd better get something out there sooner than later. Apart from all the things that are wrong, I do actually feel quite confident that I could make this a usable implementation for using SSPI/SChannel with boost::asio on Windows and avoid having to use OpenSSL, but as my time is limited as well, I probably need some help. Before I start moving any further with this, I think the next step is to think about the design, as this current POC isn't really designed at all. I've looked quite a bit at the GnuTLS implementation that Arvid was kind enough to link to as well as the current OpenSSL implementation and while I like the idea of having a "drop in replacement" which seems to be the goal of the GnuTLS implementation, I really think the current OpenSSL implementation in boost::asio is extremely well designed with the actual OpenSSL details being (mostly) abstracted away very nicely. It looks to me as if I could actually reimplement the "engine" class for use with SSPI/SChannel and get all the async behaviour, buffer handling etc. for "free". I would still need to hide some of the OpenSSL specifics currently "leaking" from the implementation, especially in the context class, but that seems comparatively trivial. My ambitious goal is, that it should be possible for the user to choose which implementation to use while getting the same behavior. I'm not really sure what would be the best way to move in that direction. One way would be to simply fork the current asio repository and rewrite the OpenSSL parts to use SSPI/SChannel instead. That would probably be the easiest, as my first goal would then be to simply make it compile without having OpenSSL available and then knowing which stub functions/classes etc. I'd need to implement. It would require a bit of cleanup later on if I actually got it to work though. Anyway, most importantly I would really like to work on this so I wanted to share this sooner than later. This is only something I'm doing in my spare time which is already limited, so don't expect too much from me but I hope you guys will appreciate my efforts as I would be extremely proud if I could actually end up contributing something like this to the boost project. Please let me know what you think. Thanks a lot and kind regards, Kasper Laudrup |
From: D. C. D. <Cam...@bl...> - 2020-07-27 13:10:07
|
Hello, I have an asio socket server on Windows with which I would like to use a thread local storage object. It appears that internally asio is using 16 worker threads to process completion handlers. Is there a way to allocate the TLS object for each internal asio thread? Forgive me if my terminology is wrong, I am pretty new to asio. Thanks! Regards, Cameron D. Cameron DeHeer Vice President, Research & Development Blaze Systems Corporation Phone: 302.733.7236 Fax: 302.733.7248 Email: Cam...@bl...<mailto:Cam...@bl...> Web: www.blazesystems.com Follow: [cid:ima...@01...5021D0] <http://www.facebook.com/blazesystems> [cid:ima...@01...5021D0] <http://www.linkedin.com/company/blaze-systems-corporation> [cid:ima...@01...5021D0] <http://www.twitter.com/blaze_systems> |