-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a stub pthreads library for THREAD_MODEL=single
#518
base: main
Are you sure you want to change the base?
Conversation
does this break pthread detection mechanisms like cmake find_package(Threads)? |
I don't know. I don't use cmake beyond building other software that uses it. Several of the comments in the linked issue are implying that, even if it might, not having these stubs is causing even more difficulty with porting software. |
3d5abda
to
a6adc10
Compare
having a stub for mutex etc is probably fine. otoh, i feel it isn't a great idea to provide pthread_create. |
This is one part of breaking up #518 into smaller PRs. This should be (IMO) the least-controversial batch of commits
This is the next part of breaking up #518 into smaller PRs. This is the rest of the commits which change the existing `THREAD_MODEL=posix` functionality. It: * _removes_ some functions which are optional and which were already nonfunctional. * (Continues to) establish a precedent of trying to remain as compatible with Open Group specifications as possible, even when there are major differences in WASI capabilities (i.e. thread cancellation) Compared to the RFC PR, the `pthread_atfork` stub has been dropped as it is now officially obsolete as of the very recent Issue 8 of the specifications.
THREAD_MODEL=single
THREAD_MODEL=single
a6adc10
to
38081ab
Compare
This is needed in order to *correctly* implement things such as cancellation handlers being invoked on pthread_exit
Performs all the cancellation actions and then calls exit()
This fixes compatibility with old versions of clang
f47ff55
to
80e0c80
Compare
Although there are also thoughts of potentially changing it, libcxx currently does require/expect pthread_create to exist. Incidentally, it performs detection whether or not pthreads is supported by looking for |
I've rebased this PR and fixed the issues that CI uncovered. I do wish to merge this, but a decision needs to be made about how to handle the "pthreads detection in existing code" issue. |
@@ -0,0 +1,21 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we call this directory pthread-stubs
?
And maybe it should live at the top level alongside dlmalloc
and emmalloc
(which override/replace libc functions too). @sunfishcode any preference?
ping? |
anyway, libcxx is not a representative application, i suspect. can you explain why having a stub pthread_create is important for you? |
The immediate reason is: I want to be able to build clang+LLVM for WASI (using @whitequark's patchset), which requires threading functions inside libcxx. The usage of types such as As far as I can tell, the only possible choices are:
The tl;dr is "I need libcxx. I am trying to avoid having to put in all of the effort needed to enable a new 'libcxx has synchronization primitives but no thread creation' build mode for libcxx. I also generally don't think omitting In general, the code I want to get ported to WASI would look something like
With full pthreads stubs in wasi-libc, this code can either be ported by doing nothing ("just" don't pass the Can you perhaps elaborate further as to why you oppose having |
(Thanks for doing this work, @ArcaneNibble) |
how about having libwasi-emulated-pthread.a to follow the precedents?
i don't want to break pthread-detection mechanisms around there, including cmake FindThreads. |
Oh! I quite like this idea! I would still want libcxx to be built with threading support enabled for both
The deliberate intention was to cause detection mechanisms to now detect "this platform has pthreads." This is why I implemented all of the stub functions s.t. they comply with the POSIX specifications (rather than just returning 0 like some other examples that have been posted in #501 ). Can we get community consensus on the approach of "put single-threaded pthreads stubs into libwasi-emulated-pthread.a but always build libcxx with threading enabled (thus causing a program to have undefined symbols if it uses libcxx threading but doesn't link the .a file)" before I go ahead and implement it? |
do you mean to make wasi-sdk ship libcxx built with LIBCXX_ENABLE_THREADS=ON? why? |
Yes, because I specifically want to easily port software which uses C++11 threading. i.e. the exact same reason why I am trying to enable pthreads stubs |
@yamt I feel like we are repeatedly talking past each other. Is there any way we can jump into a real-time discussion (e.g. IRC)? |
ping, is there some way through which we can arrive at community consensus about how this pthreads stub functionality should be named and exposed? |
This patch series first starts with a number of commits stubbing out functions in the existingEDIT: These have been split off into separate PRs and merged.THREAD_model=posix
code. According to "The Open Group Base Specifications Issue 7, 2018 edition", there are a number of mandatory functions which have not been provided. There are also some optional functions that have been partially provided in a not-useful way (e.g. get but no set function). For these, I have chosen to clean them up and remove the get functions for consistency.The remainder of the patches then build up a stub implementation of pthreads for
THREAD_MODEL=single
. I have done my best to try to make sure that all functions are as conforming as possible (under the assumption that another thread cannot ever be launched). This means that objects such as mutexes and rwlocks actually do update their state and will correctly fail when locks cannot be acquired.When an inevitable deadlock occurs, I have chosen to return EDEADLK when it has been explicitly listed as a permissible return value, and to invoke
__builtin_trap
otherwise.I have tested this by rebuilding libc++ with threads enabled and then smoke-testing Clang/LLVM-on-WASI to make sure that it can compile a simple program. I have not run any more-extensive conformance testing.
Fixes #501