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.