We changed our program to avoid the needless polling (only two PeekMessage are
needet then). We add also the PM_NOYIELD. This gives back the reaction of the
program if some other process consumes process time. But the speed is more
reduced than windows.
Your patch works for our program. It seems
Oliver Mössinger wrote:
We changed our program to avoid the needless polling (only two PeekMessage are
needet then). We add also the PM_NOYIELD. This gives back the reaction of the
program if some other process consumes process time. But the speed is more
reduced than windows.
So we actually
Jeremy White [EMAIL PROTECTED] writes:
However, this makes it clear to me that the yield
in message.c is largely moot; you need to remove both
that one and the one in ntdll/sync.c to have
any material effect on Wine timing with messages.
Actually it should be enough to not yield in
Alexandre Julliard wrote:
You can probably fix it by passing PM_NOYIELD in the PeekMessage
calls. But if your app needs a lot of CPU, restructuring the code to
avoid all the needless polling would give much better results, and
probably improve the behavior on Windows too.
That's just a
I wrote:
So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD
specified it yields execution twice (although it shouldn't at all).
Err, that should read and without PM_NOYIELD specified.
Felix
Felix Nawothnig [EMAIL PROTECTED] writes:
(The numbers slightly differ between runs for obvious reasons but they
are close enough (with an error margin of +/- 10 we could maybe make
this a real testcase))
So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD
specified it
Alexandre Julliard wrote:
So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD
specified it yields execution twice (although it shouldn't at all).
PeekMessage is going to call the server and wait on the result,
there's no way around it. The extra yield is to avoid hammering
Felix Nawothnig [EMAIL PROTECTED] 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
Alexandre Julliard wrote:
Felix Nawothnig [EMAIL PROTECTED] 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
Alexandre Julliard wrote:
since a server call is much more expensive than a Windows system call.
Would using shm fix that?
No, you don't want to put the message queue in shared memory, that's
not reliable.
shm + kernel handles for synchronization then?
Felix
Jeremy White [EMAIL PROTECTED] writes:
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
I wrote:
since a server call is much more expensive than a Windows system call.
Would using shm fix that?
No, you don't want to put the message queue in shared memory, that's
not reliable.
shm + kernel handles for synchronization then?
Wait, putting the message queue into shm isn't what I
Felix Nawothnig [EMAIL PROTECTED] writes:
I meant that using shm generally would lower the cost of a server
request and doing that extra yield would no longer be necessary
(although we'd still have the other yield due to the request itself
unless the queue is put into shm).
If you mean
I dug into this a bit further.
Felix, the extra 100 yields are coming from code I
prompted, in ntdll/sync.c; if the return from
an NtWait... is TIMEOUT, then we force a yield.
(The thread that points to more info is here:
http://www.winehq.org/hypermail/wine-devel/2005/01/0469.html)
If I back
14 matches
Mail list logo
