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

Paullgdc/telemetry ffi again #54

Closed
wants to merge 7 commits into from

Conversation

paullegranddc
Copy link
Contributor

What does this PR do?

A brief description of the change being made with this pull request.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

How to test the change?

Describe here in detail how the change can be validated.

@@ -9,9 +9,10 @@ edition = "2021"
[lib]
# LTO is ignored if "lib" is added as crate type
# cf. https://github.com/rust-lang/rust/issues/51009
crate-type = ["staticlib", "cdylib"]
crate-type = ["lib", "staticlib", "cdylib"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need lib? Note that due to the above comment, you will lose LTO and your library size will increase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a just a temporary hack to hijack the current build script and re-esxport ddtelemetry-ffi inside the profiler-ffi crate, to build and the telemetry example using the artifact built by the build-profiler-ffi script

Once I figure out how to actually build the library, I'll remove this

Copy link
Member

@ivoanjo ivoanjo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Paul 👋! Since you had asked feedback on the API (sorry it took a week), I looked at this file and the generated telemetry.h from the POV of "I'm given this thing to integrate with on my library".

So my comments are all from that POV. In particular, when I had a question, if it wasn't on this file, or on the header, I purposely did not go one level deeper into the Rust code, to hopefully give you the POV of a (*cof* very *cof*) lazy person that needs to get the job done and what was going through my head.

API design in C is for sure awful lol.

Also, I saw that in an earlier version you were using C, and now moved to C++ (although you still list the version as "C89"). I would actually suggest going back to C, as I'd expect most libraries will either be Rust or C, so I think you'd get a more realistic example.

(I am aware the profiler example is C++ ahaha. But I wish it was C as well).

Comment on lines +34 to +42
ddog_TelemetryWorkerBuilder* builder = NULL;

ddog_builder_instantiate(
&builder,
DDOG_CHARSLICE_C("ffi-test"),
DDOG_CHARSLICE_C("cpp"),
DDOG_CHARSLICE_C("C89"),
DDOG_CHARSLICE_C("0.8")
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From a consumer POV this API seems a bit awkward -- could ddog_builder_instantiate return the builder directly, rather than having the weird pointer passed in?

};
ddog_TelemetryWorkerBuilder* builder = NULL;

ddog_builder_instantiate(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ddog_builder prefix here seems a bit weird -- should it be ddog_TelemetryBuildder or ddog_TelemetryWorkerBuilder instead?

Also, a bit more minor, but profiling has usually been using _new instead of the more verbose _instantiate.

Comment on lines +44 to +47
// Set properties by name
ddog_builder_with_runtime_id(builder, DDOG_CHARSLICE_C("58a260d7-4309-45bc-a167-7a64abea3da6"));
// Set property from enum value
ddog_builder_with_property(builder, DDOG_TELEMETRY_WORKER_BUILDER_PROPERTY_APPLICATION_SERVICE_VERSION,DDOG_CHARSLICE_C("0.0.1"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was a bit confused by this, but then realized the intention here is to show that there are two styles. I'll suggest calling it out more clearly in the comments, perhaps even setting the same property twice in the two ways to make it clear how it goes.

Comment on lines +49 to +52
TRY(
ddog_builder_with_str_property(builder, DDOG_CHARSLICE_C("application.env"), DDOG_CHARSLICE_C("test")),
"Setting key application.env on builder"
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you clarify what's the semantic meaning of failing to set an str property? E.g. if I was writing an actual production integration with the API, what should I do with a failure here?

Same for other APIs -- I'm looking at the generated .h file and it's not clear to me at all how should I proceed when I get a ddog_MaybeError.

Comment on lines +65 to +68
TRY(
ddog_handle_start(handle),
"Starting the worker"
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between run and start again? And when in the application life cycle should they be called? And what happens if my application forks?

DDOG_CHARSLICE_C("libdatadog.test"),
ddog_Vec_tag_new(),
DDOG_METRIC_TYPE_COUNT,
false,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this common argument, and what does it represent?

Comment on lines +79 to +80
ddog_handle_add_point(handle, &libbdatadog_test_key, 1.0, ddog_Vec_tag_new());
ddog_handle_add_point(handle, &libbdatadog_test_key, 2.0, ddog_Vec_tag_new());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since ddog_ContextKey seems to be a struct with just an integer, consider passing it here by value (e.g. add_point(handle, test_key, ...)) rather than by reference :)

Also, is it me, or a) Is the code screaming for a "empty tags" constant (or just null) and b) Are you (potentially?) leaking the empty tags vector?

Comment on lines +94 to +95
ddog_handle_wait_for_shutdown(handle);
return 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the handle become invalid after this? Or is there any cleanup needed?

Also, similar question for the ddog_TelemetryWorkerBuilder -- did we miss cleaning it up, or was it cleaned up automatically when ddog_builder_run was called?

(And I suggest answering these as comments in the .h 😛)

if (parsed_tags.error_message != NULL) {
print_error("Parsing tags", parsed_tags.error_message);
}
ddog_handle_add_point(handle, &libbdatadog_test_key, 7.0, parsed_tags.tags);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like other functions, I have no idea what to do if this fails. Should I retry? Just shut down everything? Just ignore it?

@@ -0,0 +1,96 @@
// Unless explicitly stated otherwise all files in this repository are licensed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Paul 👋! Since you had asked feedback on the API (sorry it took a week), I looked at this file and the generated telemetry.h from the POV of "I'm given this thing to integrate with on my library".

So my comments are all from that POV. In particular, when I had a question, if it wasn't on this file, or on the header, I purposely did not go one level deeper into the Rust code, to hopefully give you the POV of a (*cof* very *cof*) lazy person that needs to get the job done and what was going through my head.

API design in C is for sure awful lol.

Also, I saw that in an earlier version you were using C, and now moved to C++ (although you still list the version as "C89"). I would actually suggest going back to C, as I'd expect most libraries will either be Rust or C, so I think you'd get a more realistic example.

(I am aware the profiler example is C++ ahaha. But I wish it was C as well).

@ivoanjo
Copy link
Member

ivoanjo commented Sep 30, 2022

Also, have you considered doing an actual implementation for one of the languages that are using libdatadog? I think having an actual, real API consumer would help uncover some of the sharp edges and issues earlier.

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

Successfully merging this pull request may close these issues.

3 participants