Jinoh Kang (@iamahuman) commented about server/queue.c:
static int update_desktop_cursor_pos( struct desktop *desktop, user_handle_t win, int x, int y ) { int updated; + unsigned int time = get_tick_count();
x = max( min( x, desktop->cursor.clip.right - 1 ), desktop->cursor.clip.left ); y = max( min( y, desktop->cursor.clip.bottom - 1 ), desktop->cursor.clip.top ); - updated = (desktop->cursor.x != x || desktop->cursor.y != y); - desktop->cursor.x = x; - desktop->cursor.y = y; - desktop->cursor.last_change = get_tick_count(); + updated = (desktop->shared->cursor.x != x || desktop->shared->cursor.y != y); Readability nit: shall this be brought closer to (x, y) updates, specifically moved into the write critical section? If so, the atomic "read-check-then-write" becomes more apparent to the reader.
In general, would it be a good idea to allow[^1] reads in `SHARED_WRITE_BEGIN`? This will let us treat each `SHARED_WRITE_BEGIN` more like an atomic transaction block where everything happens in one "unit."[^2] [^1]: Of course any other complex operations (such as calling nontrivial/blocking functions) should still be disallowed, in order to prevent starving readers too much. Reads on the other hand should execute fast; performance impact should be negligible. [^2]: Technically this will also make it easier to switch to some hypothetical "multithreaded wineserver," but this is unlikely to happen in the near future anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3103#note_59386