4 ms·
Presumably you could store the TID in every event, or otherwise check whether the TID has changed since the last time it was logged and push a (timestamp, TID)
by HALtheWise 2y ago
Presumably you could store the TID in every event, or otherwise check whether the TID has changed since the last time it was logged and push a (timestamp, TID) pair if so. Reading TID should be cheap.
- yosefk 2y agoIn what sense should reading the TID be cheap? You would need either a syscall (not cheap) or thread-local storage (the subject of TFA.) Avoiding the use of TLS by reading the TID can't really work
- HALtheWise 2y agoIt looks like the TID is stored directly in the pthread struct pointed to by %fs itself, at a fixed offset which you can somewhat-hackily compile into your code. [0] In the process of investigating this, I also realized that there's a ton of other unique-per-thread pointers accessible from that structure, most notably including the value of %fs itself (which is unfortunately unobservable afaict), the address of the TCB or TLS structures, the stack guard value, etc. Since the goal is just to have a quickly-readable unique-per-thread value, any of those should work. Windows looks similar, but I haven't investigated as deeply. [0] https://github.com/andikleen/glibc/blob/b0399147730d478ae45160051a8a0f00f91ef965/nptl/descr.h#L169 https://github.com/andikleen/glibc/blob/b0399147730d478ae451... [1] https://github.com/andikleen/glibc/blob/b0399147730d478ae45160051a8a0f00f91ef965/nptl/sysdeps/x86_64/tls.h#L80 https://github.com/andikleen/glibc/blob/b0399147730d478ae451...