On Wed Apr 22 10:06:39 2026 +0000, Charlotte Pabst wrote:
The event is created with bManualReset=FALSE, so RtwqPutWaitingWorkItem() (indirectly) resets it after the event becomes signaled. But perhaps we shouldn't rely on that - it seems unclear to me if it could be considered documented behavior. It seems like a reasonable expectation tho(?) - the threadpool worker/waitqueue has to wait on the event in some way and then become released after it fires. It also seems like we use bManualReset=FALSE together with MFPutWaitingWorkItem() in dlls/mf/sar.c. Oh yes, my bad here: I always get confused with manual reset, and I interpret it as "automatic reset", so I invert its meaning. It's not the first time. I think it makes sense that passing the automatic reset event to `RtwqPutWaitingWorkItem()` will indeed reset it.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9777#note_137326