I don't feel that strongly about it. If you think we really need it, I'll review the second version, and we'll put it in.
Ethan On Fri, Sep 13, 2013 at 1:11 PM, Ben Pfaff <b...@nicira.com> wrote: > On Fri, Sep 13, 2013 at 1:05 PM, Ben Pfaff <b...@nicira.com> wrote: >> >> On Thu, Sep 12, 2013 at 05:46:12PM -0700, Ethan Jackson wrote: >> > Assuming we really need this ability. I don't like that we have to >> > take a readlock every time we get the time. Perhaps we could could >> > have a global flag which is false unless time has ever been warped. >> > If it hasn't then we can simply do the xclock_gettime(). I think >> > that'd add a slight race, but I can't imagine it'd matter. >> >> I posted a v2 that eliminates the read-lock in the common case: >> http://openvswitch.org/pipermail/dev/2013-September/031879.html > > > > Maybe this deserves more comment. > > time/warp was introduced by itself initially. It is useful by itself in > situations where you want to advance time without actually waiting for > it to do so, but you do not care if a little extra time goes by. In fact > it is probably preferable in such situations, because it allows the tests > to help you discover more timing related bugs. > > time/stop was introduced later. It helps you write tests for things that > you otherwise couldn't write tests for because they depend on very > precise timing. For example, you can't really test NetFlow expiration > without stopping time because a really slow machine (or one using > valgrind) could go through multiple expiration periods when you expect > exactly one. > -- > "I don't normally do acked-by's. I think it's my way of avoiding > getting blamed when it all blows up." Andrew Morton > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
