On Fri, 8 Mar 2013, Juan Lang wrote: [...]
Michael Stefaniuc wrote:
i.e. commit 8099c2b9. JW says "... to more closely resemble Windows behavior. The key is to yield in a Sleep..."
I think it's really a three patch series and the first one has the clearer commit message:
commit 08c0f691cebc0994bb94bc160c080cccf8068561 Author: Jeremy White jwhite@codeweavers.com Date: Sat Oct 9 02:26:29 2004 +0000
Made NtDelayExecution with a 0 timeout yield the CPU, as it is supposed to.
commit de91a8dd0fd01da20656a4f6be423e5ae2df785f Author: Alexandre Julliard julliard@winehq.org Date: Mon Oct 11 20:11:01 2004 +0000
Implemented NtYieldExecution.
commit 8099c2b9fd5b80f35868936a6e96f732106c3286 Author: Jeremy White jwhite@codeweavers.com Date: Tue Nov 2 19:32:03 2004 +0000
Tune the behavior of Sleep() and Waitxxx() to more closely resemble Windows behavior. The key is to yield in a Sleep and in any Wait that times out.
If the ancient wisdom isn't backed by tests there's a fair chance that
it might not be applicable today. Or that it was a wrong theory
[...]
I no longer recall which app it was Jeremy was working on fixing, but there was at least one app that depended on this behavior. See Jeremy's posts on "RFC: yield on Waits" and "Threading issues".
http://www.winehq.org/pipermail/wine-devel/2004-November/030796.html
I suspect it was the Shockwave Director plugin(*). If I remember correctly it had a thread in a tight loop just calling PeekMessage() and Sleep(0) or some such. Then it had another thread that was doing the real work. But because the first thread was not yielding the second's performance suffered (even more so as the processors of the time where mostly single core).
(*) Nothing to do with Shockwave Flash, aka Macromedia Flash aka Adobe Flash.