ntdll: make NtDelayExecution a bit more efficient
Francois Gouget
fgouget at codeweavers.com
Fri Mar 8 16:38:34 CST 2013
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 at 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 at winehq.org>
Date: Mon Oct 11 20:11:01 2004 +0000
Implemented NtYieldExecution.
commit 8099c2b9fd5b80f35868936a6e96f732106c3286
Author: Jeremy White <jwhite at 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.
--
Francois Gouget <fgouget at codeweavers.com>
More information about the wine-devel
mailing list