Description
This came up on the spec call today with regards to like python and ruby. I think it will not be common in Erlang because of how we use NIFs most often as very very short function calls but there are dirty NIFs out there and others doing their own worker pools that do much more.
One example is https://github.com/edenhill/librdkafka which uses https://github.com/edenhill/librdkafka.
The process dictionary and seqtrace are not available inside the NIF code so the only option is to grab the context as a record and pass it to the NIF function call, then reconstruct it as a context with https://github.com/open-telemetry/opentelemetry-cpp
I think simply accepting that you'd be running multiple OpenTelemetry SDKs is acceptable for the very rare case someone actually wants this -- meaning the spans created in the NIF, or whatever workers the NIF communicates with, will be exported by opentelemetry-cpp and not go to the processor/exporter in Erlang.
But this means double configuration, you have to setup the C++ processors and exporter to duplicate what you have in the Erlang config.
Second option would be to create a span processor for OnEnd or an exporter in C++ that would, instead of exporting out of the node, create the Erlang span record and send that finished span to the Erlang finished span ETS table. I think this has to be done by a process, so the span would be send as a message to some process that then sends it to the regular finished span ETS table. So an optional process that accepts spans to finish would be added.
Anyway, not very important, though the second idea seems interesting to implement if anyone wants to delve into C/C++ :).
I might look at doing the second idea for Rust when there is an OpenTelemetry Rust available.