Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_keyboard.c:
+ + wl_keyboard_add_listener(keyboard->wl_keyboard, &keyboard_listener, NULL); +} + +/*********************************************************************** + * wayland_keyboard_deinit + */ +void wayland_keyboard_deinit(void) +{ + struct wayland_keyboard *keyboard = &process_wayland.keyboard; + + if (keyboard->wl_keyboard) + wl_keyboard_destroy(keyboard->wl_keyboard); + + xkb_context_unref(keyboard->xkb_context); + memset(keyboard, 0, sizeof(*keyboard)); The `wayland_keyboard_deinit` (and `wayland_keyboard_init`) functions are called in the context of the Wayland dispatch thread, and at any time during program execution. As such, they are potential sources of `wayland_keyboard` race conditions (currently with `wayland_surface_destroy`). I think for the interactions in this MR it is fine to not lock, but having a lock makes things easier to reason about (removes concerns about memory access reordering etc). Anyway, not a blocker for this MR, but something to keep in mind.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4204#note_51736