On Wed Sep 6 14:13:12 2023 +0000, Alexandros Frantzis wrote:
Recycling can be ignored, but we certainly can't have the driver crash
because a window was destroyed. The usual way to handle that is to refcount the structure associated with the window. Thanks for the clarification. Driver crashes are certainly out of the question in all circumstances; accesses to internal structures are properly protected in all of the proposed alternatives. The worst case in the simpler version is that we send an input message to a recently destroyed HWND (which I expect should be a nop), or the wrong window in the case of HWND recycling (the edge case which I was more concerned about, but seems we can now ignore). @rbernon If I am not misunderstanding the conclusion of this discussion, it would be fine to go with an approach along the lines of the simpler solution (https://gitlab.winehq.org/afrantzis/wine/-/commits/wayland-part-6-no-double-...). If this also matches your understanding, please let me know and I will update the MR accordingly.
This is also my understanding. Fwiw I believe macdrv also behaves similarly. I don't know if macdrv should be trusted as a reference of a good driver code, but at least there's a precedent.
It delegates the input message processing to the window thread, holding a reference to the host window in the event, and retrieving its hwnd from the macdrv event handler (this is different from what you are going to do, calling __wine_send_input directly). *But* the input event is received on a different thread, and I think it's possible for the Win32 window to be destroyed before the input event is processed, thus ending up using a stale hwnd.