Use libpthread primitives for OpenBSD mutexes. #82392
Open
+69
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There has been some discussion as to whether this is the right approach, centered around internal pointers in the underlying mutex structure. After much thought, let's commit this for now. The argument: * While it is true that OpenBSD has futex(2) and in fact is used in the underlying implementations in Dispatch. I'm not confident right now creating robust locking primitives by hand from futexes. It would be ideal to just delegate all of this to Dispatch, but Dispatch doesn't expose a ready-use API for mutexes. Cobbling one together might be possible, but that would take some time and finesse. * While recent versions of C and C++ have language support for mutexes, they are implemented in many cases by libpthread anyway, so there is nothing inherently gained right now by not using the pthread API other than portability. * While the concern for internal pointers for the pthread API is important, the OpenBSD is mitigated by the fact that pthread_mutex_t is pointer-valued on the platform. The concern that this might not always be the case is mitigated by the fact that this commit does not attempt to use the pthread implementation as a catch-all for all platforms. * The alternative is to use MutexUnavailable, but given Foundation has some dependencies on Mutex, this may cause problems elsewhere throughout the port.
3405691582
force-pushed
the
openbsd_mutex_pthread
branch
from
65609b2 to
3bb369c
Compare
|
@swift-ci please test. |
1 similar comment
|
@swift-ci please test. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There has been some discussion as to whether this is the right approach, centered around internal pointers in the underlying mutex structure. After much thought, let's commit this for now. The argument:
While it is true that OpenBSD has futex(2) and in fact is used in the underlying implementations in Dispatch. I'm not confident right now creating robust locking primitives by hand from futexes. It would be ideal to just delegate all of this to Dispatch, but Dispatch doesn't expose a ready-use API for mutexes. Cobbling one together might be possible, but that would take some time and finesse.
While recent versions of C and C++ have language support for mutexes, they are implemented in many cases by libpthread anyway, so there is nothing inherently gained right now by not using the pthread API other than portability.
While the concern for internal pointers for the pthread API is important, the OpenBSD is mitigated by the fact that pthread_mutex_t is pointer-valued on the platform. The concern that this might not always be the case is mitigated by the fact that this commit does not attempt to use the pthread implementation as a catch-all for all platforms.
The alternative is to use MutexUnavailable, but given Foundation has some dependencies on Mutex, this may cause problems elsewhere throughout the port.