[ovs-dev] [PATCH] timeval: Restore ability to warp time forward when time is not stopped.

Ben Pfaff blp at nicira.com
Fri Sep 13 20:24:05 UTC 2013


I'd appreciate that.

On Fri, Sep 13, 2013 at 01:22:07PM -0700, Ethan Jackson wrote:
> 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 <blp at nicira.com> wrote:
> > On Fri, Sep 13, 2013 at 1:05 PM, Ben Pfaff <blp at 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
> >



More information about the dev mailing list