-
-
Notifications
You must be signed in to change notification settings - Fork 21.5k
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
Avoid editor error reporting using resource loader thread's call queues #92426
Conversation
a5b2389
to
53abf53
Compare
@AThousandShips, thanks, but in the end I've decided to leave the |
Fair enough, but they shouldn't have used |
I'm not sure many are aware of that being possible. I wasn't until very recently myself. |
I tested the code of this PR, and now the project is open without problem. I see the errors toasts on startup and the editor does not hang. |
53abf53
to
8eb0273
Compare
8eb0273
to
f61c63e
Compare
I tested this PR on Linux, it seems to fix the linked issue partially. It fixes the potential deadlock reported by @Hilderin in #85255 (comment) with the linked MRP. It doesn't seem to fix the deadlock reported by @danny88881 with the MRP in the OP: #85255 (comment) With this PR, I still have this kind of lock on closing the MRP:
Overall it seems to me the two MRPs in #85255 are not showing the same bug. The one in the OP isn't related to the EditorToaster, it happens at runtime outside the editor. |
Thanks! |
After #91630, deferred calls happening during a resource load going on a non-main thread, are flushed on that very thread. As a result, the mesaures in place for thread-safety so that the editor UI is not updated from a non-main thread need an update, which this PR performs.
Formerly, it was enough for those pieces of code to defer the call in case the caller thread wasn't the main one. However, given the potential flush-on-non-main-thread situation, that second-hand call must explicitly be pushed to the main call queue so it eventually happend on the main thread.
In a way, this requirement introduced by #91630 is a compat breakage. However, I'd say the surface is very small and it seems to be fully solvable in the editor code itself. Maybe some extensions or plugins need to be aware of this as well and perform the appropriate changes, though.
Fixes EditorToaster deadlock in #85255 (comment).
NOTE: I haven't tested this myself.