If a session is shutdown when its command_state is already COMPLETE,
session_handle_source_shutdown calls session_set_stopped, which calls
session_command_complete which will submit the op at the head of commands again,
despite it having already been submitted.
Given that only the op at the head of commands can be in the submitted state,
tracking it as a command state makes more sense to me. And if the command state
is SUBMITTED we know not to submit the op again.
* * *
Superceded !8270
--
v3: mf: Add a SUBMITTED command state to avoid multiple submission of the same op.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8722
Unlike the message queue for which I believe we can get rid of any special handling, I don't see a way to avoid a dedicated inproc sync for user APCs. This will make sure that the sync gets created on thread creation. It could arguably be lazily allocated instead, but I don't see a reason to delay the failure to a later time and end up with successfully created but unalertable thread when they are supposed to be.
--
v2: server: Create an inproc sync for user APC signaling.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9014
--
v2: win32u: Track mouse events based on last mouse message data.
win32u: Move mouse tracking info into per-thread data.
win32u: Use internal message to hanlde NtUserTrackMouseEvent() for other thread window.
user32/tests: Add test for (no) messages during TrackMouseEvent() call.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9069