Improve the docs for I3_SYNC
I was confused by the previous state of the docs since I imagined that there is still a race possible. Thus, the images are updated to explicitly include the IPC reply from i3 (since that is an important synchronisation component). I also tried to clarify some of the text. Fixes: https://github.com/i3/i3/issues/4365 Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit is contained in:
parent
af2171d01d
commit
8a5eac3457
Binary file not shown.
Binary file not shown.
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 20 KiB |
BIN
docs/i3-sync.dia
BIN
docs/i3-sync.dia
Binary file not shown.
BIN
docs/i3-sync.png
BIN
docs/i3-sync.png
Binary file not shown.
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 13 KiB |
@ -481,7 +481,7 @@ an i3 crash resulting in the testcase being unable to communicate with i3 via
|
|||||||
IPC anymore.
|
IPC anymore.
|
||||||
|
|
||||||
[[i3_sync]]
|
[[i3_sync]]
|
||||||
== Appendix A: The i3 sync protocol
|
== Appendix A: The I3_SYNC protocol
|
||||||
|
|
||||||
Consider the following situation: You open two windows in your testcase, then
|
Consider the following situation: You open two windows in your testcase, then
|
||||||
you use +focus left+ and want to verify that the X11 focus has been updated
|
you use +focus left+ and want to verify that the X11 focus has been updated
|
||||||
@ -499,9 +499,9 @@ is($x->input_focus, $left->id, 'left window focused');
|
|||||||
However, the test fails. Sometimes. Apparently, there is a race condition in
|
However, the test fails. Sometimes. Apparently, there is a race condition in
|
||||||
your test. If you think about it, this is because you are using two different
|
your test. If you think about it, this is because you are using two different
|
||||||
pieces of software: You tell i3 to update focus, i3 confirms that, and then you
|
pieces of software: You tell i3 to update focus, i3 confirms that, and then you
|
||||||
ask X11 to give you the current focus. There is a certain time i3 needs to
|
ask X11 to give you the current focus. There is a certain time that the X11
|
||||||
update the X11 state. If the testcase gets CPU time before X11 processed i3's
|
server needs to process the requests from i3. If the testcase's request for the
|
||||||
requests, the test will fail.
|
input focus is processed before i3's requests, the test will fail.
|
||||||
|
|
||||||
image::i3-sync.png["Diagram of the race condition", title="Diagram of the race condition"]
|
image::i3-sync.png["Diagram of the race condition", title="Diagram of the race condition"]
|
||||||
|
|
||||||
@ -531,10 +531,10 @@ less robust.
|
|||||||
|
|
||||||
The real solution for this problem is a mechanism which I call "the i3 sync
|
The real solution for this problem is a mechanism which I call "the i3 sync
|
||||||
protocol". The idea is to send a request (which does not modify state) via X11
|
protocol". The idea is to send a request (which does not modify state) via X11
|
||||||
to i3 which will then be answered. Due to the request's position in the event
|
to i3 which will then be answered, again via X11. Because this answer is
|
||||||
queue (*after* all previous events), you can be sure that by the time you
|
generated via an X11 request, it will be sent to the X11 server *after* all
|
||||||
receive the reply, all other events have been dealt with by i3 (and, more
|
previous requests. Thus, you can be sure that by the time you receive the reply,
|
||||||
importantly, X11).
|
all other events have been dealt with by i3 (and, more importantly, X11).
|
||||||
|
|
||||||
image::i3-sync-working.png["Diagram of the i3 sync solution", title="Diagram of the i3 sync solution"]
|
image::i3-sync-working.png["Diagram of the i3 sync solution", title="Diagram of the i3 sync solution"]
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user