Alexandros Frantzis (@afrantzis) commented about dlls/winewayland.drv/wayland_surface.c:
/* If we have a previously requested config, we have already sent a * WM_WAYLAND_CONFIGURE which hasn't been handled yet. In that case, * avoid sending another message to reduce message queue traffic. */
BOOL should_post = surface->requested.serial == 0;
should_post = surface->requested.serial == 0; initial_configure = surface->current.serial == 0; surface->pending.serial = serial; surface->requested = surface->pending; memset(&surface->pending, 0, sizeof(surface->pending));
if (should_post) NtUserPostMessage(hwnd, WM_WAYLAND_CONFIGURE, 0, 0);
}
pthread_mutex_unlock(&surface->mutex);
- if (should_post) NtUserPostMessage(hwnd, WM_WAYLAND_CONFIGURE, 0, 0);
IIRC, the reason the post was inside the lock was to ensure that the target HWND hadn't been reassigned if the window/surface was destroyed by the (different) window thread. At some point in the various MR discussions we established that this is not something we need to worry about in general, so moving it out of the lock looks fine.
I am curious, though, under which circumstances posting that message leads to a deadlock?