On Mon Nov 3 21:58:28 2025 +0000, Byeongsik Jeon wrote:
We unfortunately can't just do IM_SET_TEXT on the main thread, due to
it not being the wine thread, and IM_SET_TEXT also needs to be handled when the mouse interacts with the native IME UI, so it is not enough to refactor it to be coupled together with macdrv_ime_process_key.
Of course this is still not completely race-free (but the previous
version also wasn't), since the thread running `- (void) completeText:(NSString*)text` and generating this event can be preempted at any time.
I have reproduced it. Since this occurs independently of macdrv_ime_process_key, we should not remove the IM_SET_TEXT event. Since it's not an ImeProcessKey driven, it call `NtUserPostMessage(hwnd, WM_WINE_IME_NOTIFY, IMN_WINE_SET_COMP_STRING, id)` in win32u/imm.c:post_ime_update. I tried reproducing the same situation on Windows, and it shows a similar pattern. The intermediate steps might differ slightly, but eventually, a WM_IME_COMPOSITION message is sent. In my opinion, this is handled by the next peek_message in the event loop, and there's no need to worry about it in macdrv_ime_process_key. We just need to keep the IM_SET_TEXT event.
How about the current version? Does that work for you?
We don't really have a need for a ime query event anyways, since that does not call into any Wine functions (and I assume this used to be the case before one of the many refactors).
We can drop `QUERY_EVENT_NO_PREEMPT_WAIT` for sure now (since it is not used by any event anymore) and all the other queries as well soon with what I am working on currently.
This is actually worse than I originally thought, since we are quite often blocking the UI main thread for extended periods of time (up to 0.3s), depending on where and how fast we can drain these events.
And as @rbernon mentioned above, we should also not be doing so outside of `NtUserMsgWaitForMultipleObjectsEx`, which macdriver currently does with that mechanism when dispatching to the main thread from any thread.