actor-framework icon indicating copy to clipboard operation
actor-framework copied to clipboard

Consider using libuv for caf-net

Open Neverlord opened this issue 2 years ago • 0 comments

The multiplexer in caf-net is a trimmed-down version of the multiplexer from caf-io. At its core, this class is basically a socket event loop. Instead of rolling our own, we could use libuv for the job. This would become an implementation detail of the multiplexer, so CAF would have no header dependencies on libuv in order to allow us to just build libuv statically by default to bundle it into the caf-net module. Of course there should be the option to use libuv from the system (e.g., for package managers).

The main benefits would be:

  1. Use more efficient socket multiplexing: kpoll, kqueue, etc.
  2. Access to existing building blocks for async DNS etc. that we could leverage.
  3. Reduced implementation overhead in caf-net (at the cost of an extra dependency).

Back when we started caf-net, we've stripped down the I/O multiplexer to have something to start iterating with. Re-implementing it with libuv might give us a more robust foundation going forward. So far, I've only skimmed the docs a while ago, but it seems like libuv allows us to control all the threading, allocations, etc. so we should be able to integrate it seamlessly.

Downsides would be managing an extra dependency (small effort, though, thanks to FetchContent) and relying on a 3rd-party project. However, libuv is the backend for NodeJS, so there's a very slim risk of them disappearing any time soon. License-wise, integrating libuv is not an issue since they use the MIT license.

Neverlord avatar Jun 13 '23 05:06 Neverlord