Fails to compile on VS14 about asio

[chriskohlhoff]

Please try the following diff and let me know if it fixes the problem, thanks.

diff --git a/asio/include/asio/detail/config.hpp b/asio/include/asio/detail/config.hpp
index 6207552..156f4e5 100644
--- a/asio/include/asio/detail/config.hpp
+++ b/asio/include/asio/detail/config.hpp
@@ -289,6 +289,11 @@
 #   endif // defined(__GXX_EXPERIMENTAL_CXX0X__)
 #  endif // ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 7)) || (__GNUC__ > 4)
 # endif // defined(__GNUC__)
+# if defined(ASIO_MSVC)
+#  if (_MSC_VER >= 1900)
+#   define ASIO_ERROR_CATEGORY_NOEXCEPT noexcept(true)
+#  endif // (_MSC_VER >= 1900)
+# endif // defined(ASIO_MSVC)
 # if !defined(ASIO_ERROR_CATEGORY_NOEXCEPT)
 #  define ASIO_ERROR_CATEGORY_NOEXCEPT
 # endif // !defined(ASIO_ERROR_CATEGORY_NOEXCEPT)

[ned14]

Yep, that worked, thank you. Tell me Chris, would you have any interest in a STL concurrent unordered map with concurrent safe erase and node splicing facilities? It could let you remove a lot of locking from io_service on POSIX and therefore substantially increase concurrency, potentially to the extent of the IOCP implementation? The single threaded performance loss is about 10% of a std::unordered_map on GCC and clang, and unfortunately over 50% on MSVC (so don't use it there until Microsoft catch up), but concurrency increases linearly with core count so it runs rings around an unordered_map even on a dual core CPU. Let me know if that sounds of interest.

[chriskohlhoff]

Are you using master? If so, the first step would be to try it in a separate implementation of an execution context, with the same members (run, run_one, stop, etc) as io_service. Are you able to put that together, at least as a partial prototype?

[ned14]

It's more that on Linux, at least, your io_service implementation contends heavily on a std::mutex when one is scheduling a large number of small work items where multiple worker threads are available to run(). ASIO makes the choice of lock configurable if I remember rightly, but it would be even better if it didn't lock at all when scheduling i/o, or when worker threads are deciding what callbacks to execute. Obviously that's a substantial refactor of your current POSIX io_service implementation, it wouldn't be something I would prototype but I can certainly supply the proposed boost concurrent_unordered_map to you (note: no Boost is required, it's completely standalone). The fact it can concurrently safe erase is an enormous difference over split ordered list concurrent hash tables.

[ned14]

For reference, my statement about ASIO io_service lack of concurrency has benchmarks at https://boostgsoc13.github.io/boost.afio/doc/html/afio/FAQ/closure_performance.html (see right hand column). v1.3 of the AFIO engine will use concurrent_unordered_map, and I should very substantially close the gap between AFIO and ASIO. v1.4 of the AFIO engine will use the new non-allocating constexpr future-promises which are essentially a functional elaboration of ASIO async_result, and with that I expect to eliminate almost all of the gap between AFIO and ASIO.

[zaphoyd]

I've also run into this issue (ASIO does not scale beyond 3-4 threads) which limits the concurrency of programs built using my WebSocket library, WebSocket++, when used with the ASIO based networking policy. If this thread turns into a serious effort to address this issue I'd be willing to put in some time, at minimum in testing & benchmarking and possibly writing code as well.

[Tyche]

The above patch introduces the following warning on VS 2015:
c:\dev_2015\project\asio-1.11.0\include\asio\detail\config.hpp(300): warning C4005: 'ASIO_ERROR_CATEGORY_NOEXCEPT': macro redefinition
1> c:\dev_2015\project\asio-1.11.0\include\asio\detail\config.hpp(286): note: see previous definition of 'ASIO_ERROR_CATEGORY_NOEXCEPT'

Either define would work
define ASIO_ERROR_CATEGORY_NOEXCEPT noexcept(true)
define ASIO_ERROR_CATEGORY_NOEXCEPT noexcept

[ryanbartley]

I see the macro redefinition warning as well.