CoWaitForMultipleHandles infinite loop

Anton Romanov at
Sat Jan 6 14:02:22 CST 2018


While looking at we
discovered that an app uses in insane amount of CPU when idling
because it makes wine enter infinite loop in
dlls/ole32/compobj.c CoWaitForMultipleHandles

This is because apartment is singlethreaded so that function enters
message_loop mode, apt doesn't define any filter and the message that
is pending does not match those defined in Com_PeekMessage. So
CoWaitForMultipleHandles loops over and over again without ever
dispatching aforementioned message.
MSDN states that
"If the caller resides in a single-thread apartment,
CoWaitForMultipleHandles enters the COM modal loop, and the thread's
message loop will continue to dispatch messages using the thread's
message filter. If no message filter is registered for the thread, the
default COM message processing is used."

Now in this case the only messages that are being dispatched are the
ones defined in Com_PeekMessage.
Is that the right behavior?
Does anyone know what is the right thing to do to mitigate this infinite loop?
Should we instead just dispatch ALL the messages if apartment does not
define a filter?


More information about the wine-devel mailing list