[general, attributes] Make the `thread.id` attribute a string

[alevenberg]

Context: https://opentelemetry.io/docs/specs/semconv/general/attributes/#general-thread-attributes

In C++, there is no guaranteed integral conversion of std::this_thread::get_id() (https://github.com/googleapis/google-cloud-cpp/pull/13151/files#r1397504258)

So we are storing the attribute as a string in our implementation. Can we update the spec to make the attribute value a string or an int?

[trask]

cc @open-telemetry/cpp-approvers

[joaopgrassi]

Friendly ping @open-telemetry/cpp-approvers

[lalitb]

In C++, there is no guaranteed integral conversion of std::this_thread::get_id()

This is correct, and applicable to both C++ and Rust. The core issue is that there isn't a universally safe and portable method to convert thread identifiers into a numeric (integer) form due to concerns around type safety. This contrasts with higher-level languages that operate atop a managed runtime environment. These higher-level languages can afford to abstract away the complexities and offer a more simplified, integer-based representation of thread identifiers.

For applications written in C++ or Rust, the realistic strategies boil down to a couple of workarounds:

• Transforming the thread identifier into a hash and using that as a unique identifier, though this comes with the usual caveats about potential hash collisions.
• Setting up a custom mapping between std::thread::id and integers, safeguarded by a mutex for thread safety.

However, both of these methods introduce extra complexity and potential performance hits, making them less than ideal solutions.

Better approach would be of representing thread IDs as strings for semantic purposes.

cc @open-telemetry/rust-maintainers @open-telemetry/cpp-maintainers

[trask]

@lalitb what do thread ids look like in C++/Rust?

@AlexanderWert @trisch-me have you run into this in ECS? it looks like ECS process.thread.id is also a number type

[lalitb]

what do thread ids look like in C++/Rust?

In C++, thread id is an abstraction over the internal platform-specific representation or implementation of a thread, and it may or may not be an integer. The C++ Standard does not mandate std::thread::id to be a numeric value; as long as it is unique, can be converted to string for debugging purposes, and can be compared. As an example, the below stuff runs successfully for posix/gcc, but is not guaranteed to succeed for other compilers/platforms - https://godbolt.org/z/Eje4eWvcj

#include <thread>
#include <sstream>
#include <string>
#include <iostream>

int main() {
    std::thread::id threadId = std::this_thread::get_id();
    std::ostringstream oss;
    oss << threadId;
    std::string threadIdStr = oss.str();
    std::cout << "ThreadId as string: " << threadIdStr << std::endl;
    // below statement can throw exception for certain compilers/platforms if conversion fails
    std::cout << "ThreadId as long :" <<stol(threadIdStr);
}

o/p:
ThreadId as string: 140550312396608
ThreadId as long :140550312396608

Rust being more secure, unlike C++ it doesn't even provide a built-in, straightforward way to imply a numeric conversion from a ThreadId.

[trask]

The C++ Standard does not mandate std::thread::id to be a numeric value; as long as it is unique, can be converted to string for debugging purposes, and can be compared.

Just to clarify, sometimes it will be a string that represents a number, e.g. "140550312396608", and sometimes it will be a string that doesn't represent a number, e.g. "bZUPbvaY4d"?

[lalitb]

Just to clarify, sometimes it will be a string that represents a number, e.g. "140550312396608", and sometimes it will be a string that doesn't represent a number, e.g. "bZUPbvaY4d"?

Thats correct.

[trask]

Other than it being a breaking change, changing thread.id from number to string seems ok.

I don't think the number-ness of the value is important (other than, again, of it being a breaking change).

@tedsuo @jack-berg @jsuereth any thoughts on the defacto stability status of thread.id?

[trisch-me]

@mjwolf do you know anything about type of thread.id, if we had problems with number type before?

[mjwolf]

Given the OTel definition of thread.id is "Current “managed” thread ID (as opposed to OS thread ID).", I don't have any objection to this being a string.

The ECS field usually refers to the OS thread ID, which should be a number. The OS thread ID is a number in all major OSs.

With OTel, I think there should be an additional attribute that is specifically for OS thread ID, with number type. It's a bit of a potential problem in ECS that the type of thread ID to use in the field is not well defined, and users could use it for both runtime or OS thread ID. I haven't seen heard of any actual problems related to it in ECS, but by having separate attributes in OTel, any problems could be avoided.

[joaopgrassi]

but by having separate attributes in OTel, any problems could be avoided.

@mjwolf But what does that mean for ECS users? That would be breaking for them, no? (if we introduce a thread.os.id) 🤔