I think ASIO is highly regarded so if we were starting from scratch, ASIO seems like a good choice. However, rewriting the existing networking code using ASIO seems like a lot of work and I'm not sure what we really gain from it. The current networking code has been very stable (not touched is 3-4 years). AFAIK, we also don't have any serious networking bugs or missing features that would justify such a major rewrite.

I'm intending to do small steps, like this one, so definitely no thousand line diffs :)

A migration would get us using

• interfaces with a good chance of becoming part of the standard
• no more lengthy cmake configures (esp. on Windows) since it's header-only
• using scalable I/O completion instead of select() on Windows
• cleaner code with no more C-style book keeping
• and best of all a generic threadpool, that we can start migrating the various dedicated-thread-per-world 🗺 components into using

using scalable I/O completion instead of select() on Windows

AFAICT, bufferevent is backed by IO completion ports and not select().

It also looks like ASIO uses the same "iocp" API, judging by the win_iocp file naming:
https://github.com/chriskohlhoff/asio/tree/6f51579783df620267db1f1def799607d5497810/asio/include/asio/detail/impl

and best of all a generic threadpool, that we can start migrating the various dedicated-thread-per-world world_map components into using

Having separate threads for generating, lighting, etc. means the OS scheduler ensures some fairness between them. Imagine you queue 1000 chunks for generating and suddenly the server stops accepting client connections because the authenticator task doesn't get a chance to run.

In a thread pool, you also need to be very careful about blocking code. e.g. the world storage thread wouldn't work as a thread pool task since it's based on blocking file IO.

libevent is blocked in a select for me, but asio is in an iocp call

Yeah good point with the fairness, certainly we shouldn't post work onto the io_context that's accepting connections. Such a pity there's no cross platform support for async file operations... In any case we're still some ways away from a thread pool, this PR is only for the networking side :)

Could you measure the difference in time between full rebuild of master as-is and with this PR? The problem with header-only libraries is that often they increase compilation times significantly. The Factorio team had to get rid of boost for this reason - it increased their build times by order of tens of minutes.

Sure, hold on a bit.