On Apr 19, 2010, at 7:11 PM, Holger Freyther wrote:
> I once had a patch to use clock_gettime but I discarded it as the call is
> slower than gettimeofday. I have a micro benchmark for that here[1].
Also tangentially related, I found an article about the lack of clock_gettime
on Mac OS X.
http
On 04/16/2010 11:50 PM, Yong Li wrote:
> Hi All
>
> The default implementation of JS Date is calling currentTime() (by
> jsCurrentTime()), so it assumes currentTime() returns current UTC time,
> and system UTC time can be changed. However, currentTime() is also used
> in most cases as a system ti
On Apr 16, 2010, at 8:50 AM, Yong Li wrote:
> The default implementation of JS Date is calling currentTime() (by
> jsCurrentTime()), so it assumes currentTime() returns current UTC time, and
> system UTC time can be changed. However, currentTime() is also used in most
> cases as a system tick c
I agree with the fact that it should not rely on currentTime() as it
currently does. It is probably the root of bugs like
https://bugs.webkit.org/show_bug.cgi?id=31550 and many others.
On Fri, Apr 16, 2010 at 11:50 AM, Yong Li wrote:
> Hi All
>
> The default implementation of JS Date is calling c
Just raised a bug for this. Except the usage in jsCurrentTime(), all calls
to currentTime() in both JavaScriptCore (threading, TimeoutChecker,
ProfileNode...) and WebCore (Timer, and many other cases...) are time
counting and assume it never goes backward. If we make currentTime() return
the system
Hi All
The default implementation of JS Date is calling currentTime() (by
jsCurrentTime()), so it assumes currentTime() returns current UTC time, and
system UTC time can be changed. However, currentTime() is also used in most
cases as a system tick count, which means it should always be monotonica
6 matches
Mail list logo