Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Klebsch, Mario (Mario.Klebsch_at_[hidden])
Date: 2019-03-15 07:58:19

Hi,


Am 14.03.2019 um 17:48 schrieb Vinnie Falco via Boost-users <boost-users_at_[hidden]<mailto:boost-users_at_[hidden]>>:

We've had Asio for over a decade now, but there is a shortage of
experts. Some people believe this shortage is because Asio in
particular (and thus, Networking TS since they have identical
interfaces) is "difficult to use.“

When I started using boost:asio, the biggest surprise to me was to see, that boost::asio also is a great library for synchronous networking, especially for writing programs that need to support IPv4 and IPv6 or using socket options. Almost everything is easier than directly using the plain C socket API.

The library probably was named asio, because async operations were the main improvement to the classic socket API, but that name kept me from trying it earlier. :-(

And there is one think, that IMHO should be handled in the tutorial: Lots of C programmers are familiar with using select() and lots of exciting code is structured the way to use select. Boost::asio can use null_buffers to get a similar behavior as select(): Being notified when data is ready. I know, this has a runtime performance penalty compared to using real async reading, especially on windows system, but it may it easier to convert existing code to boost::asio.

In the past days, I tried to use boost::asio::coroutine for some async operation. But that approach is hardly documented and seems to have lots of pitfalls.

I am also struggling on using synchronization primitives in async code. Unfortunately, there is no async_lock in boost::mutex and there is the requirement to call unlock() on the same thread as lock(). My synchronous code used a boost::mutex to protect against changing a std collection while iterating it to perform a possibly blocking network operation on each entry. I had to create an async version of that code and gave up after some days and simply used an additional thread.

I got all my test cases working, but I was not able to make sure, that the event handler will never block when trying to lock on the collection and I was not able to make sure that unlock() is called from the same thread, that was calling lock().

So it would be nice to find some advice or tutorial on how to use synchronization primitives (mutex, condition_variable) to synchronize async event handlers and conventional threaded code.

73, Mario
--
Mario Klebsch                     Actia I+ME GmbH
Mario.klebsch_at_[hidden]<mailto:Mario.klebsch_at_[hidden]>        Dresdenstrasse 17/18
Fon: [phone]           38124 Braunschweig
Fax: [phone]            Germany