Wayland: Defer event thread initialization to late initialization#111493
Merged
Repiteo merged 1 commit intogodotengine:masterfrom Nov 6, 2025
Merged
Wayland: Defer event thread initialization to late initialization#111493Repiteo merged 1 commit intogodotengine:masterfrom
Repiteo merged 1 commit intogodotengine:masterfrom
Conversation
This race condition made me pull my hair. `wl_display_roundtrip` has its own little event loop, which apparently conflicts hard with the always-running event loop thread. I kinda assumed that it would be thread-safe thanks to its internal `wl_display_prepare_read` call that the docs talk about but that's clearly not enough. Luckily this method is called very few times and the only dangerous instances are in the initialization routine, which first starts the thread and then does various roundtrips. Libdecor has also some internal roundtrips of its own which would often fail. Starting the thread after all initialization fixes the issue. Tested this by spamming *lots* of `wl_display_roundtrip` in `WaylandThread::init()` with and without this fix.
This was referenced Oct 10, 2025
Contributor
Author
|
Welp I've just noticed that I've been extremely somehow both generic generic and verbose in this description 😅 In simple words, this fixes a completely random stall that would happen (mainly at initialization) when the engine tried to send a roundtrip message. Both the main event loop and the synchronous roundtrip method would dispatch events, even from different threads, breaking things in a subtle way. The fix is to be sure that we're not roundtripping when the thread is doing stuff. |
bruvzg
approved these changes
Nov 6, 2025
Member
bruvzg
left a comment
bruvzg
left a comment
There was a problem hiding this comment.
I have not encountered any random stalls on startup, but change make sense and seems to be working fine.
akien-mga
changed the title
Contributor
|
Thanks! |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This race condition made me pull my hair.
wl_display_roundtriphas its own little event loop, which apparently conflicts hard with the always-running event loop thread.I kinda assumed that it would be thread-safe thanks to its internal
wl_display_prepare_readcall that the docs talk about but that's clearly not enough.Luckily this method is called very few times and the only dangerous instances are in the initialization routine, which first starts the thread and then does various roundtrips. Libdecor has also some internal roundtrips of its own which would often fail. Starting the thread after all initialization fixes the issue.
Tested this by spamming lots of
wl_display_roundtripinWaylandThread::init()with and without this fix.Also added the usual comment-of-knowledge for good measure :P