PerformanceCounterFrequency fix

Rein Klazes wijn at
Thu Jan 27 04:45:21 CST 2005

On 26 Jan 2005 09:59:14 -0800, you wrote:

> My concern isn't the number of cycles. It sounds like the function runs
> very quickly, even faster than in Windows. That's great news.
> But I am concerned about blocking or preemption. I assume that the new
> call doesn't hit the wineserver, right? Is there any other thread sync
> required (critical sections, etc) for gettimeofday() which might cause
> the new implementation to block? I don't know how it is implemented, but
> it sounds like a "system call" which makes me suspicious. I know that
> Windows developers class QueryPerformanceCounter as a "system call
> that's safe to use in real time" so that's why I am trying to keep tabs
> on it.  

Because the wineserver is not involved at all, I did not believe there
to be substantial differences between Windows and Linux. For both there
is switch to kernel mode, that is a syscall, which is in itself
expensive compared to a user function call. Both will need to have some
mutual exclusion or critical section when they access the hardware
clock. Net result will depend on optimization details where I believe
Linux has some distinct advantages. 

> Anyway, thanks for your attention to this issue. It sounds like Receptor
> (our product) will be fine with this change. ... mo

I think so too. And if it is not, it can be fixed.


More information about the wine-devel mailing list