On Thu Nov 2 11:59:28 2023 +0000, Alexandros Frantzis wrote:
This compare-exchange operation needs to be explicitly atomic or locked, to avoid the following thread interleaving scenario:
- [Wayland] keyboard enter hwnd1
- [Window] destroy hwnd1, up until and including the `focused_hwnd ==
surface->hwnd` check above. 3. [Wayland] keyboard leave hwnd1 4. [Wayland] keyboard enter hwnd2 5. [Window] continue destroy hwnd1, setting `focused_hwnd = NULL`, so hwnd2 loses focus This also means that all other accesses to `focused_hwnd` should ideally also be locked or explicitly atomic (to guarantee memory order). Looking at subsequent commits, I think both approaches would work, but since we are going to have a lock anyway (for xkb_state), perhaps it would be simpler to just use that for all keyboard synchronization needs.
Right, I'm not completely sure we really need to clear the HWND from wayland_surface_destroy, which would then leave only the even thread responsible for writing focused_hwnd, and make the mutex unnecessary, but I'll make it work the same way as the cursor for consistency.