So write a new driver. Yes, I know, that's a lot of work.
The thread-per-client sin derives in large part from having synchronous APIs first.
Every API, every project, needs an async-first approach.
Even then, many many all-synchronous-all-the-time thread-per-client apps will get written, but at least it will be possible to write thread-per-CPU, async-I/O apps where those apps need to scale.
While I would love for every API to have an async counterpart, there is a non-trivial cost in term of complexity, latency and performance to implement an async API.
Cost in developer time, yes. Cost in latency and performance? No! That's the whole point of async I/O: to improve latency, performance, and scalability.
It's much harder to rewrite software to use async I/O than it is to write it to use async I/O in the first place. It's also much harder to write software using async I/O than sync I/O. Therefore it's all about economics and forecasting. If you can forecast needing to scale soon enough, then start with async I/O, otherwise increase revenue and profits first then rewrite. For many companies developer time is a larger item on their budgets than the cost of extra servers and power and all that, which is why we have so much thread-per-client software -- it's a natural outcome.
The thread-per-client sin derives in large part from having synchronous APIs first.
Every API, every project, needs an async-first approach.
Even then, many many all-synchronous-all-the-time thread-per-client apps will get written, but at least it will be possible to write thread-per-CPU, async-I/O apps where those apps need to scale.