Given our current level of explicit guarantees (i.e. none), I agree with Daniel about this.
There are two questions of ordering/timing in the code:
1. Whether mir_surface_configure_cursor() will be processed by the server before mir_surface_set_state().
2. Whether mir_surface_configure_cursor() will have been processed by the server by the time we release the surface/connection.
We don't provide explicit guarantees for either of the above (AFAIK, please correct me if we do), although one could say that at least (1) is the expected behavior. We either need to make explicit guarantees about ordering (and ensure we keep our word == tests), or wait for each operation to complete.
Since providing the guarantees is outside the scope of this MP, I propose we just reinstated the waits for now, and have a discussion about the ordering topic.
Given our current level of explicit guarantees (i.e. none), I agree with Daniel about this.
There are two questions of ordering/timing in the code:
1. Whether mir_surface_ configure_ cursor( ) will be processed by the server before mir_surface_ set_state( ). configure_ cursor( ) will have been processed by the server by the time we release the surface/connection.
2. Whether mir_surface_
We don't provide explicit guarantees for either of the above (AFAIK, please correct me if we do), although one could say that at least (1) is the expected behavior. We either need to make explicit guarantees about ordering (and ensure we keep our word == tests), or wait for each operation to complete.
Since providing the guarantees is outside the scope of this MP, I propose we just reinstated the waits for now, and have a discussion about the ordering topic.