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 -~----------~----~----~----~------~----~------~--~---