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
