labath wrote: Yes, the issue is two instances of the atomic counter in two libraries (well, one of them is an executable). I'm not sure why `GetTickCount` would be a better solution though. It returns time in milliseconds, which definitely too coarse-grained. Even if we used an API with greater resolution (I don't know which, but I assume Windows has one), I don't think we can completely rule out collisions.
I've recently been porting some code to aarch64, and one of the things I ran into was that (some) arm cpus have a (relatively) low frequency of the hardware clock, which broke code which assumes that functions like `absl::Now()` return monotonically increasing values (usually code which tried to measure the throughput of something, which then crashed due to division by zero). So even if we went with something time-based, I would would still want to add some sort of a backup counter for an additional source of entropy. However, if we have that, I'm not sure if the time is useful. The new pipe name is `lldb.pipe.<pid>.<address_of_atomic>.<value_of_atomic>` (the old one was without the middle member), which seems unique enough (first value identifies a process, second one an address within that process and the last one a value at that address). https://github.com/llvm/llvm-project/pull/123905 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
