mstorsjo added a comment.
In https://reviews.llvm.org/D38704#897935, @majnemer wrote:
> I don't think we should depend on LLVM for the locking stuff. This sort of
> infrastructure is in the same bucket as the demangler which we haven't really
> solved.
>
> I *do* find it weird to do it this way
majnemer added a comment.
I don't think we should depend on LLVM for the locking stuff. This sort of
infrastructure is in the same bucket as the demangler which we haven't really
solved.
I *do* find it weird to do it this way though. I think you should have some
mutex functions which include r
mstorsjo added a comment.
In https://reviews.llvm.org/D38704#892479, @zturner wrote:
> I'm a little nervous about re-inventing a poor man's version of a reader
> writer lock. Can we not just copy LLVM's?
I had a closer look at this, and noticed the following:
- The LLVM RWMutex class on wind
zturner added a comment.
I'm a little nervous about re-inventing a poor man's version of a reader writer
lock. Can we not just copy LLVM's?
Comment at: src/UnwindCursor.hpp:20
#ifndef _LIBUNWIND_HAS_NO_THREADS
- #include
+ #ifdef _WIN32
+#include
May
mstorsjo added a comment.
In https://reviews.llvm.org/D38704#892479, @zturner wrote:
> I'm a little nervous about re-inventing a poor man's version of a reader
> writer lock. Can we not just copy LLVM's?
I guess I could have a look to see how much extra either kitchen sink it would
bring. Si
mstorsjo created this revision.
Herald added a subscriber: mehdi_amini.
This makes sure that the FDE cache is thread safe.
This requires building with `_WIN32_WINNT >= 0x0600`.
The alternative would be to skip the FDE cache altogether if building without
threads.
https://reviews.llvm.org/D387
