Closed uatuko closed 5 months ago
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.
@RavikumarTulugu please take a look at #26.
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.