test case demonstrating PeekMessage give up timeslices

[Jeremy White]

Alexandre Julliard wrote:
> Felix Nawothnig <felix.nawothnig at 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