Re: [asio-users] Any solution for polymorphic SSL stream support?

[Aaron Koolen-B. <aar...@gm...>]

So I did some debugger stepping and also used the asio handler debugging
and here is what I got from a simple strand wrapped handler with client
calling socket.async_read_until

async_read_until(net::bind_executor(strand_,[](error_code, size_t)){});

@asio|1502836377.436372|0*1|so...@00...ync_receive
@asio|1502836377.442603|>1|ec=asio.system:0,bytes_transferred=10
@asio|1502836378.156284|1*2|strand_executor@0000028F63C49C80.dispatch
@asio|1502836378.156365|>2|
@asio|1502836378.714019|2*3|so...@00...ync_receive
@asio|1502836378.714118|<2|
@asio|1502836378.714416|<1|
@asio|1502836378.714483|>3|ec=asio.system:0,bytes_transferred=10
@asio|1502836379.271424|3*4|strand_executor@0000028F63C49C80.dispatch
@asio|1502836379.271515|>4|
@asio|1502836379.830781|4*5|so...@00...ync_receive
@asio|1502836379.830873|<4|
@asio|1502836379.831099|<3|
@asio|1502836379.831133|>5|ec=asio.system:0,bytes_transferred=10
@asio|1502836380.386317|5*6|strand_executor@0000028F63C49C80.dispatch
@asio|1502836380.386402|>6|
@asio|1502836380.942522|6*7|so...@00...ync_receive
@asio|1502836380.942581|<6|
@asio|1502836380.942743|<5|
@asio|1502836380.942777|>7|ec=asio.system:0,bytes_transferred=10
@asio|1502836381.550245|7*8|strand_executor@0000028F63C49C80.dispatch
@asio|1502836381.550304|>8|


The strand is used to call the composed operation's operator() every time
another async_read_some completes. This is how I thought it worked and was
what I was talking about. I have yet to hand test multiple streams and/or
with ssl but I imagine it will be similar.

Of course, as you mention there are optimisations to avoid as much extra
processing if it's not required but still, the strand mechanism is being
called and there is some critical section work and strand callstack
checking. Whether this ends up being a major problem I don't know yet but I
prefer to know these things so I can make some upfront design decisions.

One thing that was doing my head in was this asio_handler_invoke business,
but I think I got my head around it the reason for it. It does however seem
to be quite painful for any composed operation to have to supply these
overloads. With Networking TS it seems even more work is required in
associated_executor specialisations.

One related thing I noticed when stepping through the code was that there
was often multiple calls to invoke, sometimes from a handler helpers
namespace and all that did was call invoke again in the asio namespace.
What's the reasoning for this?


Thanks



On Wed, Aug 16, 2017 at 2:27 AM, Vinnie Falco <vin...@gm...>
wrote:

> On Tue, Aug 15, 2017 at 7:19 AM, Vinnie Falco <vin...@gm...>
> wrote:
> >...
>
> Sorry, that post has a small inaccuracy.
>
> > io_service::strand()'s dspatch mechanism is intelligent: if the caller
> > is already on the strand then it performs an efficient continuation
> > instead of going through the dispatch mechanism. You can inspect that
> > code here:
>
> This is the correct link:
>
> <https://github.com/boostorg/asio/blob/b002097359f246b7b1478775251dfb
> 153ab3ff4b/include/boost/asio/detail/impl/strand_service.hpp#L58>
>
> io_service::strand has overhead, no question. A popular alternative is
> to just call io_service::run() from a single thread then you don't
> need a strand. If you want to take advantage of multiple cores, use
> multiple instances of io_service each with its own single thread
> calling run(). This greatly simplifies code, no need to worry about
> concurrency. You just have to keep the objects balanced with respect
> to the number of connections they are handling at once.
>
> Thanks
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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
>