[Bro-Dev] Shipping CAF with Broker?

[Dominik Charousset]

> On Tue, Feb 13, 2018 at 10:31 AM, Robin Sommer <robin at icir.org> wrote:
>> I was wondering the other day if we could add CAF as submodule to
>> Broker

I can understand where you’re coming from. Dependency management in C++ is lackluster, to say the least. However, baking CAF into Broker in this way is not trivial and can break many, many things.

CAF headers are included in public broker headers. This means users of libbroker must be able to find those headers in the system paths. You could install CAF headers via CMake along the Broker headers, but that would override any other local CAF installation. Worse, if a user installs CAF from a different source afterwards you could produce an ABI clash when compiling a libbroker application with the wrong CAF headers. It might even compile fine, as long as the API remains compatible, but produce very nasty hard-to-debug errors at runtime.

Moving *all* CAF headers out of Broker headers could solve this, but it requires a lot of pimpl boilerplate code to make everything CAF opaque. Completely hiding away the CAF actor system also takes away any opportunity for integrations. For example, we are currently thinking about how we could integrate Broker with VAST. Locking away the actor system would take away many benefits of integrating Broker. For one, we would have to run two distinct actor systems in the same process instead of using one and getting all the scalability benefits from it. Two actor systems means two schedulers that either constantly fight for resources or leave performance on the table. If each scheduler gets only half of the available HW via config that would waste a lot of CPU bandwidth if one scheduler is idle but the other at capacity. Performance aside, not having access to the Broker actor system would potentially require us to duplicate a lot of code for using Broker types in VAST. Of course this is also prone to error now, because any change in Broker no longer automatically updates the serialization code in the now detached actor system.

Long story short, doing this would shut a lot of doors for us. Did you consider using something like CMake’s External Project [1] feature or Conan [2]? There is a Conan recipe for CAF (contributed by a user a while ago) that could make life for Bro users easier. I’m happy to work on the recipe if it isn’t working out of the box right now, if that would work for you as an alternative.


    Dominik

[1] https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
[2] https://www.conan.io/