Francois Gouget wrote:
I think it's really a three patch series and the first one has the clearer commit message:
Made NtDelayExecution with a 0 timeout yield the CPU, as it is supposed to.
I agree that this is the correct behaviour for the "zero timeout" case. The comments that I submitted with my patch were incorrect, because I misread the existing code. The patch that I submitted would not have changed this behaviour, though it did reorganize a few lines of code.
I had proposed to change the "nonzero timeout" case. If the caller specifies a non-zero timeout value, the existing code calls:
1 if the timeout is negative: NtQuerySystemTime 2 NtYieldExecution 3 begin loop: 3.1 NtQuerySystemTime 3.2 select
We break out of the loop when "select" has waited the specified time, and was not interrupted by a signal. (Right? Please tell me if I've misinterpreted the code again.)
I suggested changing it to:
1 NtQuerySystemTime 2 begin loop: 2.1 select 2.2 NtQuerySystemTime
To explain:
* I think there is no need to call sched_yield before blocking on select. (But I haven't yet come up with a way to prove it.)
* We no longer need to measure how long sched_yield made us wait, so we can reorder the NtQuerySystemTime calls. The break condition is unchanged, so the second NtQuerySystemTime call is often skipped.
http://www.winehq.org/pipermail/wine-devel/2004-November/030796.html
Thanks, I will look at this.
-- graham