http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #9 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-01 03:48:06 CDT --- Not seen here in 1841 iterations overnight, judging from runtest's $? = 0 return code (without logs). Ubuntu Intrepid, wine-1.3.29, warn+heap, no PulseAudio, Timidity restarted so as to grab ALSA's dmix instead of PA.
but isn't that PeekMessage loop in MMSYSTEM_MidiStream_Player() kind of busy?
As the comment says, it's there to drain all messages. The wait happens in start_header: GetMessage. `top` shows that Timidity is busy, not Wine, so I see no indication of a busy loop. I'm still not familiar enough with windows messages to tell whether PeekMessage is superfluous and goto start_header -> GetMessage would be enough, i.e. GetMessage will return old message.
Another interesting input would be: what did the tests do when the issue arises? Perhaps WINETEST_REPORT_SUCCESS would show it's always at the same test.
What does Valgrind have to say? I'm asking because a time out in a critical section may be misleading, because it's often enough a consequence of an earlier trouble (like audio underruns occurring after the app's main thread crashed).