actor-framework / actor-framework/actor-framework
Consider using libuv for caf-net
- 主要言語
- C++
- スター
- 3.4k
- フォーク
- 572
- 平均マージ
- 3日 14時間
- マージ済み PR(30日)
- 3
説明
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.
コントリビューションガイド
評価
この issue はまだ評価されていません。