-
Notifications
You must be signed in to change notification settings - Fork 10
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
Conversation
@@ -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"] |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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).
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") | ||
); |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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
.
// 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")); |
There was a problem hiding this comment.
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.
TRY( | ||
ddog_builder_with_str_property(builder, DDOG_CHARSLICE_C("application.env"), DDOG_CHARSLICE_C("test")), | ||
"Setting key application.env on builder" | ||
); |
There was a problem hiding this comment.
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
.
TRY( | ||
ddog_handle_start(handle), | ||
"Starting the worker" | ||
); |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
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()); |
There was a problem hiding this comment.
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?
ddog_handle_wait_for_shutdown(handle); | ||
return 0; |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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 |
There was a problem hiding this 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).
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. |
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.