-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
Allow for platform Thread implementation override #52734
Conversation
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.
Looks good to me, besides the formatting issues.
Fixed formatting and added comment. |
@akien-mga isn't this PR against the contribution best practices? Reduz mentioned them recently on Twitter https://docs.godotengine.org/en/stable/community/contributing/best_practices_for_engine_contributors.html These changes are useful only in very special cases like console porting. Dangling |
Seems good to me, please squash the commits into one after final edits (see PR workflow for instructions). |
I don't think console porting is a "very special case". It's something a significant number of users need to do or get access to to publish their games on consoles. Adding a documented opt-in preprocessor define for that doesn't strike me as particularly problematic. For console porters, or people porting to some niche platforms, that means that they don't need to do a hard fork of the engine to add a platform port (instead, they can just drop their platform code in the I don't think this PR goes against the contribution best practices. It doesn't modify everyone's Thread implementation for a niche use case - it adds an entry point to allow defining a custom one, which is not even compiled if not defined. |
In that case "platform_thread.h" doesn't make sense anyway, should be stubbed somehow with some informative comments, thread class stubs, asserts, defines. Previously it was virtual class implemented per platform and now it's |
To clarify from my side. The general policy is to integrate what is needed by the community, this includes companies using the engine, even those that need this to make ports to consoles easier to maintain. If something is not wanted by the community, or it is not possible to add it due to legal reasons (like this case), at least the project will always have a compromise to make hooks available for this to happen and, thus, minimize the amount of forked codebase needed. |
I would still add a comment in that line of code that reads like "Overriding the platform implementation is required in some proprietary platforms". |
I don't think it's necessary to make a stub for this. Custom implementation just need to match the interface of However, it's true that enforcing a |
Agreed, just a single PLATFORM_CUSTOM_THREAD_H define that points to the include is probably enough. |
Replaced |
Looks great. Just remember to update the |
397f631
to
e9723ef
Compare
Done. |
Thanks! |
Cherry-picked for 3.4. |
EDIT: Implements godotengine/godot-proposals#3277.