On Mon Feb 9 15:48:38 2026 +0000, Rémi Bernon wrote:
Well the start address is mostly a detail, we could very well put some ntdll address there if necessary. The necessity to keep that thread absolutely hidden on startup is more of an issue. I know it's not happening on Windows but how confident are we that it needs so be like that? At what point is it okay to spawn a thread? That thread needs to be able to communicate with other application threads, especially it needs to be able to send window messages, otherwise it becomes a bit pointless to have and cannot replace Wayland thread, or be used to simplify macOS driver much either. We could maybe use only Wine internal hardware messages, trying to not leak anything into user space but that becomes tricky and error prone. A bit of side note, having all the async I/O done in a dedicated thread (and not interrupting the thread which requested IO) has a sync issue when GetOverlappedResult is used (and not GetOverlappedResultEx). Windows docs demand GetOverlappedResult() to be ever called from the same thread which requested I/O, and for a reason. The problem is that GetOverlappedResult() can skip event wait if IOSB is already filled with something not STATUS_PENDING. IOSB is filled before the completion event is set. So if IOSB completion is not interrupting the thread which correclty calls GetOverlappedResult() (delivered to a different thread), IOSB can be filled, app's IO thread sees that without waiting for event and continues to next IO, resetting the event. And then the IOSB completion thread sets the event, leading to premature completion of the next GetOverlappedResult() and it returning before completion. This is a side note because it is not like it works reliably now (currently the completion can be delivered through another thread as well), but maybe something to be kept in mind if we are going to be redesigning then.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10058#note_129213