Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClientWorkload bindings unstable ABI #11298

Open
Wonshtrum opened this issue Apr 12, 2024 · 0 comments
Open

ClientWorkload bindings unstable ABI #11298

Wonshtrum opened this issue Apr 12, 2024 · 0 comments

Comments

@Wonshtrum
Copy link

Wonshtrum commented Apr 12, 2024

The ExternalWorkload of foundationdb allows to load client compiled shared object as workloads in the FoundationDB simulation. This can be used to load layers written in other languages as long as it can be compiled to a shared object and binds on ClientWorkload.h API.

The use of C++ for the workload bindings makes the ABI dependent on the compiler and standard library used to compile the fdbserver.
This proved to be an issue and became apparent in our integration of the foundationdb-rs simulation, where transitioning from version 7.1 to 7.3 resulted in sudden crashes (segmentation faults). The cause, as detailed in a forum post, was attributed to the compiler switch from gcc to clang, altering the memory representation of a std::string.

Beyond the immediate risk of breakage, the need to meticulously reproduce the compilation environment for the entire project just to ensure workload integration is quite burdensome.

Moreover, the reliance on C++ for cross-language integration presents limitations. While there are options like Zig, Java with JNI, and potentially Carbon, all other languages must develop their own wrapper to interface with the simulation. This convoluted process of C++ -> C -> Language -> C -> C++ adds unnecessary complexity and overhead.

It would be far more straightforward if FoundationDB exposed C bindings directly. This approach would stabilize the ABI, reduce compilation environment requirements, and foster greater interoperability across diverse language ecosystems.

To ensure compatibility with currently developed workloads (mainly the JavaWorkload), retaining the C++ bindings could be considered. However, alongside this, making C bindings available as an alternative would offer a more versatile solution. This approach would provide developers with the flexibility to choose between C and C++ bindings based on their specific requirements, while still addressing the challenges of stability and integration across different language ecosystems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant