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.