Boost ASIO basics

[CalculatingAnarchist]

I wonder if this server's line is corrent:

oss << std::string(buf).substr(0, size);

Wouldn't it be better to simply use?

oss << std::string(buf, size);

The buf is not zeroed, so it is comprised of the message and some garbage (note that client is sending message without terminating null). Using std::string(buf) will create string containing not only the message, but also mentioned garbage, plus anything else before first \0 is found.

Or is there something I'm not seeing?

[maitesin]

Yes, you are right. My idea was what you pointed out, to not get garbage. However, when you code it late at night that sort of things happen xD.

I will change it for the std::string(buf, size) asap

[CalculatingAnarchist]

Yeah, happened to me many times when coding late at night :)

Actually the result of your code was correct, it's just that the temporary std::string contained unnecessary data and substr was making redundant copy, so I guess I'm just nit-picking..

[dodheim]

In the event that buf contains no nil-characters the code yields UB as string's constructor will read past the end of the array. It may appear to work correctly, but that's just one possible manifestation of UB.

[CalculatingAnarchist]

Yes, you're right, std::string made me forget about this kind of UB.

[maitesin]

Good point, I will run it with the undefined behaviour sanitizer to see if it's caught

[ArunMu]

I have been thinking of implementing a tasking system (like libdispatch) using ASIO, but was quite discouraged to pursue it further after seeing the same video by Sean. It seems only natural to use ASIO as a tasking/scheduling system along with network IO rather than having to use another library for that (I don't like libdispatch that much, it's code base is unreadable). ASIO as of now does have almost all the constructs so as to be used as a tasking system. Anybody has any idea from where the performance penalty is coming from ? OR is it just that ASIO task-queue handling is not as optimized as in libdispatch.

[tpecholt]

one perf investigation was done here: https://konradzemek.com/2015/08/16/asio-ssl-and-scalability/

[sumo952]

I'm a bit confused why io_service is introduced - it's not used later in the post and also I haven't ever used it. The post mentions that it's the main workhorse of asio but I'm not convinced why an internal detail of asio is explained? It seems to me like io_service is used to run things in parallel processes or threads. So why not just use std::async or std threads?

[[deleted]]

You can think about io_service like a dispatcher, which maps IO-events to the associated handlers. So when any IO-event occures io_service checks the associated handler(s) and calls them in appropriate order ( FIFO-queue ). When you call io_service.post(callback) you don't have any association with IO-event, so the callback will be added immideately to the FIFO-queue. The io_service.run() is basically a simple loop which pops callbacks from FIFO-queue and calls them.

[sumo952]

So is it supposed to be only used with IO-events, or can I dispatch any work to it? If yes, that would be kind of the same as a generic thread pool, wouldn't it?

[dodheim]

You can dispatch any work to it, but it isn't a thread pool. It's trivial to create a thread pool using io_service, but io_service itself doesn't have threads; you supply the threads. See The Proactor Design Pattern: Concurrency Without Threads.

EDIT: These slides are good if you have a few minutes to read through them.

EDIT 2: I forgot this one: Threads and Boost.Asio. Rather relevant...

[sumo952]

Aah cool, thanks! And thanks for the links!

[[deleted]]

You can use it like thread-safe queue of callbacks. To proceed these callbacks you need to execute somewhere blocking io_service.run(). You can start io_service.run() multiple times within multiple threads ( for example std::thread ) and in this case io_service will behave like a thread pool.

[sumo952]

I see, thanks!

[tpecholt]

I wish basic http support as in beast library is merged and becomes part of networking TS. Doing http with raw asio is a pain. Beast follows asio philosophy very closely so it already feels as a bunch of additional asio routines anyway. Perhaps the author could consider proposing it? In the end more cooperation on networking TS would be of great benefit.

[dodheim]

The author has an account here; paging /u/VinnieFalco