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.
