uatuko
Asio
It's been mentioned in #17 (multiple times) that using Asio would be advantageous.
😟 Complications
While it should be possible to replace libuv with Asio there are a few complications.
- Asio comes with two variants (boost and non-boost) so supporting both can be a bit complicated. Perhaps, C++20 concepts might be able to help?
- Asio is licensed under Boost Software License which doesn't look to be compatible with MIT license. So at least part of the code will need to be BSL licensed if using Asio directly.
- Both Asio and Boost Asio repos seem to be maintained by a single person. The lack of maintainers is concerning.
- While there are examples and some documentation, Asio is missing a lot of details. e.g. What does this line do?
No asio is always maintened now but the future of asio is Boost.Cobalt. You should see it
I did some initial work to get something working with asio in #23 but couldn't get it to match libuv's performance.
I feel allowing application code to use asio (or cobalt) in a non-blocking way while keeping libuv for gRPC I/O is probably going to be better choice. #23 should already allow this and I'll try to work on an example.
If anyone is willing to take another stab at integrating asio at the core, it's much appreciated 🙏.
Please provide compile time switches to switch between asio and libuv. performance related issues take a bit of time to investigate, leaving switches will allow ppl to investigate in future. The eventual use case of the library is fiber <----grpc-----> fiber , when fibers are used, there is no need for callbacks. Your library is much small and clean, atleast the app code looks much simpler and clean.
