[PATCH] D59676: Make Parallel.h build with libc++ on Windows.
Billy Robert O'Neal III via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Mar 22 12:25:51 PDT 2019
BillyONeal added a comment.
> 'assumes' in what way? If concrt140.dll uses msvcp140.dll internally but no STL objects are passed from user code (built with libc++) to ppl functions to concrt140.dll, things should be fine for example.
STL objects are passed over the concrt140.dll boundary. For example, _TaskCollection et al. are passed around there and they contain exception_ptr objects. I don't have an explicit example of "this will cause doom" but these kinds of ODR problems tend to be the "impossible bug that you have to investigate for weeks" territory. Combine that with multithreading and that will likely be unpleasant to investigate.
> From what I understand, COFF is less symbol-name-based than ELF
COFF is just as symbol name based, but the operating system linkage model is namespaced per-module on Windows vs. process-wide on POSIX. So each particular DLL can have their own concept of what vector::vector is. But if you pass pointer to vector over the DLL boundary, nothing will protect you and you get the usual ODR problems.
> Since that's a problem with the normal MSVC standard library, this seems like the biggest issue here. (But in practice, things seem to work fine so far.) But it's also independent of the libc++ part.
That's true; this problem is existing. Note that this would have been okay in MSVC++2012, when std::mutex was itself powered by ConcRT. std::mutex is no longer powered by ConcRT because too many customers complained about being unable to use std::mutex in with other platform synchronization primitives like SRWLOCK or CRITICAL_SECTION.
> The concrt + mutex incompat issue might mean we have to move off concrt eventually
Indeed, this is what we are recommending people do. Notably, our parallel algorithms implementation (should I get permission from our lawyers to contribute it to libc++, still pending :/) avoids any ConcRT interaction and calls into the Vista threadpool directly. I'm assuming you folks don't care about Windows XP support?
Billy3
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59676/new/
https://reviews.llvm.org/D59676
More information about the llvm-commits
mailing list