Eventually consistent tree #1281
Merged
Conversation
This file contains 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
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## next #1281 +/- ##
==========================================
+ Coverage 52.03% 52.21% +0.17%
==========================================
Files 64 64
Lines 13609 13771 +162
==========================================
+ Hits 7081 7190 +109
- Misses 6528 6581 +53
|
yshui
force-pushed
the
eventually-consistent-tree
branch
7 times, most recently
from
6cbd94e
to
f65cbf1
Compare
Why do we need this? This is because, firstly, in the X protocol, events, errors, and replies are in a single stream to begin with, so it's not "unnatural" to put them back. And, some replies have to be handled in the correct "context". Say, the X window tree look like this: A / \ B C `C` is the new window, so send a query tree request for it, and you receive: > Event: Reparent B to C > Query tree reply: C has child B (Remember events, and replies are all in a single stream) If you handle the reply before the event, which is what will happen if you do `xcb_query_tree_reply(c, xcb_query_tree(c, ..))`, you will think window `B` appeared in 2 places. Also with this change the `x_handle_error` in `ev_handle` is move into `x_poll_for_event`. It just makes more sense to there. Signed-off-by: Yuxuan Shui <[email protected]>
wm_tree_new_window is splitted into 3 steps: creating the window object (wm_tree_new_window), adding it to the hash table (wm_tree_add_window), and attaching it to its parent (wm_tree_attach). wm_tree_reparent is splitted into wm_tree_detach and then wm_tree_attach. Signed-off-by: Yuxuan Shui <[email protected]>
If a toplevel is reparented, then destroy, any WM_TREE_CHANGE_CLIENT events currently queued will reference the freed toplevel node. Note this doesn't happen when the toplevel is destroyed directly. Because in that case it will be turned into a zombie, and is guaranteed to only be freed after the client change event is handled. With this commit, when a toplevel is killed (i.e. destroyed or reparented), all currently queued tree changes will be updated to reference the zombie instead. Signed-off-by: Yuxuan Shui <[email protected]>
Signed-off-by: Yuxuan Shui <[email protected]>
This is part of the effort to remove reliance on the X critical section for internal consistency. The rational will be explained in later commits when it is complete. Instead of using server grabbing to guarantee that our tree is synchronized with the X server, this commit moves the wm tree to an "eventually consistent" model, utilizing the newly introduced async X request infrastructure (See commit: "x: add support for receiving replies as part of the event stream"). The algorithm is like this: let's look at each tree node individually, every node has a list of children. If this list consistent with the X server for each of the tree nodes, the entire tree is consistent. Let's also define a "partial consistency" concept. A tree is partially consistent, if for all the nodes in the tree, their lists of chilren are either consistent, or empty. Meaning some nodes might exist on the X server, but not replicated on our side. If a node's parent isn't in our tree, we call that node "orphaned". (Conveniently, a toplevel can never be orphaned, because the root window is always in the tree.) To achieve partial consistency, when each node is discovered (either via a CreateNotify from the server, or via a QueryTree request, you will see later), we set up an event mask on it to receive further updates, and then send a QueryTree request for it. The trick is that the reply to the QueryTree request will be processed in order with all the other events, errors and replies. Assuming the tree started out partially consistent, it will still be partially consistent after we processed the reply. Because the reply contains up-to-date information about that node at that point in time; and we have also processed all events that came before that reply, so all other nodes are consistent too. Further more, the tree will stay partially consistent, because the event mask we set up will keep bringing us new information for the newly discovered node. This partial consistency will eventually become full consistency after all of our requests to the X server have completed. Note this means we might start rendering with a partial window tree. In practice, that should hardly be noticeable. (The explanation above glossed over many implementation concerns, some of those are documentation in code comments.) Signed-off-by: Yuxuan Shui <[email protected]>
Signed-off-by: Yuxuan Shui <[email protected]>
Signed-off-by: Yuxuan Shui <[email protected]>
yshui
force-pushed
the
eventually-consistent-tree
branch
from
f65cbf1
to
f126d47
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
... read the commit messages, i am tired.