-
Notifications
You must be signed in to change notification settings - Fork 172
ld: Added fallback thread synchronisation for libc++ workaround on Windows #2256
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
Open
RogerSanders
wants to merge
1
commit into
ares-emulator:master
Choose a base branch
from
RogerSanders:ld-threading-workaround
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -1,12 +1,20 @@ | ||||||||||||||||||||||||||
| #pragma once | ||||||||||||||||||||||||||
| //started: 2017-01-11 | ||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
| #if !defined(USE_ATOMIC_FLAG_NOTIFY_FALLBACK) && !defined(_MSC_VER) && defined(_WIN32) | ||||||||||||||||||||||||||
| #define USE_ATOMIC_FLAG_NOTIFY_FALLBACK | ||||||||||||||||||||||||||
| #endif | ||||||||||||||||||||||||||
|
Comment on lines
+4
to
+6
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
| #include <ares/ares.hpp> | ||||||||||||||||||||||||||
| #include <nall/decode/mmi.hpp> | ||||||||||||||||||||||||||
| #include <vector> | ||||||||||||||||||||||||||
| #include <cmath> | ||||||||||||||||||||||||||
| #include <thread> | ||||||||||||||||||||||||||
| #include <atomic> | ||||||||||||||||||||||||||
| #ifdef USE_ATOMIC_FLAG_NOTIFY_FALLBACK | ||||||||||||||||||||||||||
| #include <mutex> | ||||||||||||||||||||||||||
| #include <condition_variable> | ||||||||||||||||||||||||||
| #endif | ||||||||||||||||||||||||||
| #include <functional> | ||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
| #include <qon/qon.h> | ||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
Oops, something went wrong.
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 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.
Uh oh!
There was an error while loading. Please reload this page.
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.
My only concern with going this route, is I'd like to strip out the entire alternate implementation if/when we cut over to the Microsoft STL, which is being discussed (or if/when the libc++ ticket is resolved). If we tie it to MacOS platform support on older versions, support for which has already been dropped, it's not clear to me when the alternate implementation would be cut. Ares could benefit greatly in other areas from better use of modern threading approaches, particularly as we move away from the nall threading implementation, and I feel like having this slower, more error prone threading method in there muddies the waters. To properly support older MacOS versions, we'd have to carry this same dual-system threading model into other parts of the software, or just use the worse version, both of which seem like significant costs to me.
Uh oh!
There was an error while loading. Please reload this page.
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.
I'll add here though, it's possible to set the "USE_ATOMIC_FLAG_NOTIFY_FALLBACK" define externally, IE, through a CMake rule or CXXFLAGS. If you do want to do an unsupported build targeting an older MacOS release. This would allow you do that without having to modify the source, at least under this changeset today. Future changes elsewhere in the code would probably cause more problems over time.
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.
I see the platform support question as a totally separate concern, myself. I'm not proposing re-lowering the macOS deployment target. I just think if we're adding a workaround like this, we may as well provide complete information in the code about what that workaround enables. I do not think that the mere presence of this definition impacts our goals or criteria for whether something should be removed or an OS dropped, for whatever reason.
One other thing: I am not sure I personally see a time horizon where ares drops support for libc++ on Windows. A large plurality of homebrew and emulator developers target libc++ via MSYS2/MinGW on Windows, and from my experience I do not see that situation changing in any near-term timeframe. Even if LLVM ships an update that improves the underlying implementation of atomic flag waits, the code being introduced here will still be fairly long-lived in ares, I would expect.
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.
I'll defer to @LukeUsher on what he thinks is the right way to go here. We could adopt the preprocessor change you propose here, I'm not strictly opposed to it. Shifting the platform/compiler detection logic centrally to CMakeLists might be more appropriate if it's going to be a pattern that's replicated or kept for the longer term though, rather than just a temporary workaround.
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.
I honestly have half a mind to just fix it in llvm-project myself and be done with it, but I can't spare the time for a few more weeks.