-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
ResourceLoader
: Support polling and get-before-complete on the main thread
#93695
Conversation
dddd759
to
96526f1
Compare
96526f1
to
ec61c50
Compare
ResourceLoader
: Support polling and get-before-complete on the main theadResourceLoader
: Support polling and get-before-complete on the main thread
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.
Code makes sense
// This local poll loop is not needed. | ||
break; | ||
} | ||
thread_load_lock.~MutexLock(); |
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.
This makes me think a branch I made some time ago to allow unlocking and re-locking of MutexLock
is needed, it was just a hypothetical idea then but will revive it and open a PR if it works well still, to avoid potentially hacky solutions
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.
Good point, but I think this may not be really a good thing to do depending on the kind of mutex now we have #93701. I haven't checked it yet, but I'm suspicious of this.
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.
The issue was something else in the end.
Thanks! |
Fixes #92844.
In #92844 it was told that, in reality, polling in a loop in a single frame was never actually supported and that the MRP worked on earlier versions because on them the engine wasn't fully using the freedom such a constraint gave until recently. Therefore, my first idea was to consider the issue a documentation problem.
However, I realized that it was not that hard to support both suboptimal usages (polling in a loop and getting the result before the load completed). And so is that this PR does.
I'm labeling this as enhancement because, again, those usages were never supported and this PR is making them officially supported for the first time. Nonetheless, I'm also warning about them in the docs.