<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 7:39 PM, Vadim Chugunov <span dir="ltr"><<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I suppose there's also an option #3: "declare that LLVM only supports the threads-posix flavor".   As long as configure script gives a clear error message...<br>
<br></div>It should be noted, though, that <span class="il">MinGW</span>'s pthreads mutexes are likely to perform worse than LLVM's home-grown ones: <a href="http://sourceforge.net/p/mingw-w64/bugs/344/" target="_blank">http://sourceforge.net/p/<span class="il">mingw</span>-w64/bugs/344/</a> </blockquote>
</div><br>FWIW, I *very strongly* prefer this option.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We are already seeing an increasing interest in using LLVM in multithreaded contexts at least, and I have a concrete need to add multithreaded support to LLVM. It would be really, really terrible to be unable to use extremely basic and standardized primitives for this such as std::mutex and std::call_once.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I don't really care that MinGW's mutexes would be slow. The current usage patterns of LLVM don't put them in the critical path, and in the future it seems like there has to be a non-terrible way of implementing MinGW's standard library without such sorrow. And ultimately, this is just a MinGW bug. It is hardly the only one that makes this platform somewhat suboptimal.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The standard library std::mutex and std::call_once implementations are going to get better and more widely available. It seems a mistake to continually burden ourselves with coping with bad instances.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">My 2-cents.</div></div>