Alexandre Julliard wrote:
Felix Nawothnig felix.nawothnig@t-online.de writes:
But then that "extra" NtYieldExecution should not depend on !PM_NOYIELD since PM_NOYIELD doesn't have any effect on Windows, right?
It has an effect for Win16 apps, they need to release the Win16 lock. We could add a yield in the PM_NOYIELD case, but Win32 apps won't use PM_NOYIELD anyway so I doubt it would make a difference, and keeping it that way allows Winelib apps to tweak the behavior if needed.
Ostensibly, it also effects whether or not a WaitInputIdle returns or not, but I'm not sure I fully understand this.
But I have to admit I'm bothered; you seem to be refusing a patch that makes Wine more correct.
PeekMessage() is more lightweight on Windows than it is on Wine, but I can still write bad code that chokes the system by spin looping on PeekMessage on Windows.
I can imagine a case where a bad programmer has two threads and depends (not intentionally, but through accident) on one thread starving the other thread of CPU time such that a race condition never occurs. I don't have an example, but I have seen behavior like that, notably with IE and PowerPoint (although I think the case was with some other signalling method, not PeekMessage).
Thus, I think it's reasonable to try to preserve relative timing on Wine as closely as we can, even if it creates some overall performance degradation for poorly designed apps. (Famous last words, I'm sure I'll shortly be screaming about why is Wine suddenly so slow <grin>).
Can you point out examples of misbehaving programs so that we can go see just how bad the impact is?
Cheers,
Jeremy