PerformanceCounterFrequency fix

[Rein Klazes]

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. 

[snip]
>  
> 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.

Rein.