Looks like I'm the only one interested in this - abandoning.

Apologies for the delay in replying to this.

Addressed review comments from @EricWF .

Fixed a few paths.

@EricWF: Ping?

@EricWF: Ping?

Thanks for these patches!

In D30459#689461, @rs wrote:

Thanks for reviewing. Before I commit could you tell me if I need to update any build systems e.g. buildbots ?

Fixed minor omission.

Perhaps change config.h and remove the definition there and adjust other places accordingly?

Different approach: Externalize these functions only for the external-thread-api library variant.

Different take on the patch: Externalize this function only for the externally-thread-api variant.

Committed as r295963.

Updated to address comments from @rengolin.

Ping?

Ping?

I've raised PR31966 to poke this :)

Abandoning: @jmolloy has committed a semantically equivalent patch: https://reviews.llvm.org/rL294949

Abandoning: @jmolloy has committed a semantically equivalent patch: https://reviews.llvm.org/rL294948

Re-based.

Re-based on trunk.

Addressing review comments: Get rid of the tab characters.

Address review comments: Get rid of the unnecessary pass id definition in the llvm namespace.

In D29630#670876, @EricWF wrote:

In D29630#670873, @rmaprath wrote:

Sorry for the delay, I've updated the patch with all the comments addressed.

@EricWF: Got one question before I commit: The sleep_for function in the dylib (thread.cpp) is now quite small. Is there a particular reason to keep it there? I was wondering if we should move that bit to the <thread> header altogether.

Removing the definition in the dylib would be ABI breaking.

Sorry for the delay, I've updated the patch with all the comments addressed.

Abandoning - forgot cfe-commits....

Sorry, I meant -DLIBCXX_ENABLE_ASSERTIONS=ON.

@EricWF: My downstream builds have -DLLVM_ENABLE_ASSERTIONS=ON by default and they are showing some failures after this commit. Log attached:

In D28316#636700, @EricWF wrote:

In D28316#636686, @rmaprath wrote:

(btw, do those docs updates land on some web URL automagically when committed?).

Assuming the builder isn't broken then yes, the docs should automagically update within ~3 minutes.

I think we should point out on the docs that _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL is only meant for libc++ developers / testers. The purpose of this library variant is to:

• Demonstrate that libc++ can be built with threading support externalised. We use pthreads as the underlying implementation in this case because that's the one we can easily test on any platform. I don't think anyone wants to distribute this library variant to users; they would rather compile libc++ for pthread directly instead.
• Write tests that applies to the LIBCXX_HAS_EXTERNAL_THREAD_API variant. For example, I hope to write a test to check that the produced libc++ dylib has no references to pthread_ symbols within it. Such a test will ensure that the core sources of libc++ remains pthread-free (all threading should be wired through the threading API).

If a library vendors really wants to distribute a variant of libc++ with the threading support externalised, they should use a custom __external_threading header to replicate the behaviour of _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL.

Hope that makes sense?

All of that makes sense. I think you could write those docs better than I could. Would you be willing to update them?

This is much better (few nits inline). And many thanks for the docs update (btw, do those docs updates land on some web URL automagically when committed?).

In D28229#634278, @compnerd wrote:

I dont think that making Win32 threading an external one makes much sense unless we also do the same for pthreads. Its just as valid a threading model as pthreads, so why give preferential treatment to that? (Sure, there are more buildbots using it, but thats not a strong technical justification).

I will commit this now to get the testing working again. Thought of putting up the patch for review in case if there is a better way to do this.

Most of this is no longer needed. I'll submit patches for the parts that are actually needed (e.g. nanosleep) later on. Thanks.

Ping.

Ping.

Gentle ping.

Gentle ping.

LGTM. Needs approval from @EricWF or @mclow.lists.

Patch updated with more context.

Abandoning (replaced with D27575/D27576).

Abandoning as this has been replaced with D27575.

In D27204#613177, @EricWF wrote:

In D27204#613172, @rmaprath wrote:

In D27204#613122, @EricWF wrote:

My main issue with this patch (and D27206) is that there are now two different CMake options for building two different external threading libraries. I would much prefer having libc++abi use libc++'s __threading_support header and cxx_external_threads library.

I would like to do that too!

But I always viewed libcxx and libcxxabi as two independent libraries that should be usable on their own. In this case, binding libcxxabi to __threading_support from libcxx sounded wrong, because __threading_support is something internal to libcxx (e.g. all the functions there are prefixed with __libcpp_ - there may be other libcpp-isms arising from __config in there too).

Ironically I've always viewed libcxxabi as fully dependent on libcxx (and personally I would like to see the repos merged; Although using libc++ w/o libc++abi would still be supported).

Is that not a concern? I could give it a shot and try to merge the two APIs into one if not.

It's not a concern. Libc++abi already depends on libc++ internals to build (See the #include "__refstring" in stdlib_stdexcept.cpp`).

In D27204#613122, @EricWF wrote:

My main issue with this patch (and D27206) is that there are now two different CMake options for building two different external threading libraries. I would much prefer having libc++abi use libc++'s __threading_support header and cxx_external_threads library.

On the other hand, disabling <exception> would mean disabling some parts of the library as well (in this case, std::promise::set_exception). Perhaps that's a bad path to follow. Not sure.

In D26458#594069, @EricWF wrote:

There are cases where it is useful to be able to name std::nested_exception while exceptions are disabled.

In D26458#590865, @rmaprath wrote:

Not sure if either of these tests add much value to the no-exceptions variant, using std::nested_exception with such a library seem pointless to me. Perhaps marking these as UNSUPPORTED is a better fix?

Not sure if either of these tests add much value to the no-exceptions variant, using std::nested_exception with such a library seem pointless to me. Perhaps marking these as UNSUPPORTED is a better fix?

LGTM.

In D26139#587587, @mclow.lists wrote:

I think it might be better to add TEST_TRY and TEST_CATCH(...) macros defined like

@rogfer01 said at the top that he didn't want to add "a magical TEST_TRY macro" - and I agree. Someone tried that in another review, and I nixed it there.

Would it be more cleaner to separate out the exceptions-related tests into their own functions? So, we'd have the two functions test_withexceptions() and test_noexceptions(); the former will only be invoked when testing the normal library variant, the latter will be invoked for all the library variants.

This looks sensible to me. I'll let @EricWF approve.

This looks fine to me. I'll let either @compnerd or @jroelofs approve.

In D24864#570954, @vitalybuka wrote:

Thanks, done D25636

In D24864#570935, @vitalybuka wrote:

Maybe?

- if (UNIX AND NOT (APPLE OR CYGWIN))
+ if (LIBCXXABI_ENABLE_THREADS AND UNIX AND NOT (APPLE OR CYGWIN))
list(APPEND LIBCXXABI_SOURCES cxa_thread_atexit.cpp)
endif()

In D24864#570924, @vitalybuka wrote:

So there is:

• Looking for __cxa_thread_atexit_impl in c
• Looking for __cxa_thread_atexit_impl in c - not found

and libcxx is configured with -DLIBCXX_ENABLE_THREADS=OFF

Committed as r284128.

@EricWF: Gentle ping.

Patch re-based on the latest trunk.

In D21803#567774, @tavianator wrote:

In D21803#556857, @EricWF wrote:

@rmaprath I'll merge this if needed. Feel free to commit your patch first.

Yeah, @rmaprath I'm happy to rebase this over your patch.

Added some comments to @EricWF's feedback. Will check back tomorrow (falling asleep...)

Committed as r283726.

Committed as r283441.

Final patch to be committed, with all the remaining comments addressed.

First batch of XFAIL fixes.

In D24562#561442, @Eugene.Zelenko wrote:

Looks like patch was not committed.

LGTM too.