actor-framework / actor-framework/actor-framework

Consider using libuv for caf-net

Open
#1,424 0 comments 3 reactions 0 assignees View on GitHub
idea
Dominant language
C++
Stars
3.4k
Forks
572
Avg merge
3d 14h
Merged PRs (30d)
3

Description

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.