Or I can use OS::TimeCurrentMillis which returns milliseconds as
'double', avoiding these int64_t traps.

On Fri, May 29, 2009 at 5:29 PM, William Hesse <whe...@chromium.org> wrote:
> OK, I see now why the cast to unsigned worked.  OS::Tick is non-monotonic on
> Windows
> (wraps every 50 days), and so you want to end if either 200 ms is up or the
> timer has wrapped.
> This is the case diff > 200 or diff < 0.  Casting to unsigned makes the diff
> < 0 case wrap to diff > 200.  This is tricky, and should be commented.
>
> Alternatively: if ( current_time < start_time ) { start_time = current_time;
> }
> fixes the wrapping case by resetting the timer, which is safe.  This
> separates
> the two cases (time > desired interval) and (time has wrapped), and makes
> sure
> that enough time elapses even if it has wrapped.  I think this is clearest:
> while ( OS::Ticks() < start_time + 200 * 1000 ) {
>    if ( OS::Ticks() < start_time ) start_time = OS::Ticks();
>    ...
> }
>
> Or if you don't feel safe repeatedly calling OS::Ticks, save the value.
>
>
>
> On Fri, May 29, 2009 at 3:12 PM, <tobias.k...@googlemail.com> wrote:
>>
>> I don't think either is really correct. The implementation of OS::Tick
>> can wrap around ways before reaching the int64 or uint64 limit because
>> its implementation eg. on windows has a max value of uint32*1000 and
>> then starts over with zero
>>
>> So when started_us is before and ended_us after an OS::Tick wrap-around
>> you will have problems. Using an uint64 at least avoids the infinite
>> loop you get with int64, but it can result in terminating too early (ie.
>> before 200ms are over).
>>
>> http://codereview.chromium.org/115918
>
>
>
> --
> William Hesse
> Software Engineer
> whe...@google.com
>
> Google Denmark ApS
> Frederiksborggade 20B, 1 sal
> 1360 København K
> Denmark
> CVR nr. 28 86 69 84
>
> If you received this communication by mistake, please don't forward it to
> anyone else (it may contain confidential or privileged information), please
> erase all copies of it, including all attachments, and please let the sender
> know it went to the wrong person. Thanks.
>
>

--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to