I agree. This is also my case.
While I can understand Ruben focuses on using async libs "all the way", unfortunately I don't have that luxury (or honestly the knowledge). In fact, some of the "protocols" / APIs I must support allow requesting large amount of data, thus I don't want a single request from one client to block all other clients.
As I mentioned in a previous email (seems like mailman hasn't generated a URL I can link to), my approach would be to offload the individual pieces of sync or heavy work to a thread_pool. The main event loop would still be single-threaded, dispatching those pieces to the thread pool. I've added code demonstrating this approach to https://github.com/anarthal/servertech-chat/issues/44.
When everything is async, including talking to remote RDBMS's, maybe that one big request gets "suspended", allowing other (independent) requests to make progress, but in my case with a non-async DB layer to talk to, I don't think a single-threaded server is a viable solution.
Would you mind sharing protocols or RDBMs without a sync-only interface are you interested in? These could make good C++ libraries in the future. I envision a future where almost every system has an async interface, as it happens in Python or Node. Until that future comes, the thread_pool solution seems the best. Thanks, Ruben.