Andrey Semashev
Andrey Semashev
> @Lastique is this issue is still relevant? As you can see in the source, the fine-grained headers are still missing. So, yes, it is still relevant.
`GetCurrentThreadId` could be called from anywhere, including the standard library. Is there a problem with it being called? Did you collect any backtraces from where it is called?
> Refer to folly, `GetCurrentThreadId` is slow. That link does not indicate that `GetCurrentThreadId` is slow. It does cache its value in one code path, but it also provides `getCurrentThreadID`...
BTW, see these: https://stackoverflow.com/a/15008330/4636534 https://stackoverflow.com/a/12909560/4636534 So I seriously doubt `GetCurrentThreadId` is the problem.
Here's a benchmark for different types of mutexes: [test_mutex.cpp.txt](https://github.com/user-attachments/files/16550846/test_mutex.cpp.txt) Compile with MSVC 14.3: ``` cl /O2 /EHsc /I . /DNDEBUG /MD test_mutex.cpp /link /LIBPATH:stage\lib ``` On Windows 10, on my...
What compiler and compiler options were you using?
I can't test it myself on an AMD system, so I can't explain your results with any confidence. My only theory is that it could be related to the performance...
Note that `searched-lib` was spread across various Boost libraries during the modularization effort. If you want to switch away from it, you need to update all places where it was...
Is this still pending some changes? If it is, please, convert it to a draft.
@grafikrobot Note that clang-cl build [failed](https://ci.appveyor.com/project/Lastique/log/builds/51831676/job/qb9kpwd9qn9fjk7x#L559) in AppVeyor CI.