I saw we use Seconds(-1) represent infinity in current code.
```
./3rdparty/libprocess/include/process/future.hpp: bool await(const
Duration& duration = Seconds(-1)) const;
./3rdparty/libprocess/include/process/latch.hpp: bool await(const
Duration& duration = Seconds(-1));
./3rdparty/libprocess/include/process/process.hpp:bool wait(const UPID&
pid, const Duration& duration = Seconds(-1));
./3rdparty/libprocess/include/process/process.hpp:bool wait(const
ProcessBase& process, const Duration& duration = Seconds(-1));
./3rdparty/libprocess/include/process/process.hpp:bool wait(const
ProcessBase* process, const Duration& duration = Seconds(-1));
./3rdparty/libprocess/src/process.cpp: if (duration == Seconds(-1)) {
```
On Fri, Mar 11, 2016 at 12:14 AM, Joris Van Remoortere <[email protected]>
wrote:
> Duration and TimePoint were introduced to map to the types in C++ (
> http://en.cppreference.com/w/cpp/chrono).
>
> Duration is negative so as not to surprise users when they do TimePoints A
> - B and end up with a positive duration when B > A. You could imagine a
> user of these writing code to check if their maintenance window is in the
> past:
>
> Duration remaining = Now - Scheduled;
> if (remaining < 0) {
> // Don't use offer.
> } else {
> // Still `remaining` time to use offer.
> }
>
> This logic would compile correctly and likely pass review because it is
> intuitive; however, if duration was an absolute value, then it would be a
> bug.
>
> To represent infinity we currently wrap the Duration with an Option. The
> None state represents infinity. You can find this in the protobufs.
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Wed, Mar 9, 2016 at 11:29 PM, Alexander Rojas <[email protected]>
> wrote:
>
> > IMO durations should not be negative. The problem with having them define
> > an infinite period is the following:
> >
> > Lets say you want to compute the duration between two durations A and B:
> > C = A-B;
> > if A < B, C is negative and it will be infinite.
> >
> > I one want’s to check for the case mentioned in [1] about sleeping 0
> > marked with a negative duration, I think adding an explicit `if` is
> better
> > since it reflects the intention.
> >
> > So in to conclude:
> >
> > 1. Duration operations should always be positive so A-B is effectively
> > |A.underlying_type - B.underlying_type|.
> > 2. We do need a constant or an specific trait to represent an infinite
> > duration.
> >
> > > On 09 Mar 2016, at 17:20, Klaus Ma <[email protected]> wrote:
> > >
> > > One case I can image is to use negative value for forever duration?
> > >
> > > ----
> > > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > > Platform OpenSource Technology, STG, IBM GCG
> > > +86-10-8245 4084 | [email protected] | http://k82.me
> > >
> > > On Wed, Mar 9, 2016 at 8:21 PM, Alex Rukletsov <[email protected]>
> > wrote:
> > >
> > >> Folks,
> > >>
> > >> I've recently realized that durations we use in mesos (stout's
> > `Duration`
> > >> and `DurationInfo` protobuf) are based on signed integers. Negative
> > >> duration concept is a bit strange to me, so I googled around a bit and
> > >> found an interesting thread [1].
> > >>
> > >> Was it an explicit intention to allow `Duration`s to be negative? Do
> we
> > use
> > >> this feature? If yes, maybe we can introduce a class representing time
> > >> delta (can be negative) and base `Duration` on top of it guaranteeing
> > it is
> > >> always non-negative?
> > >>
> > >> My ultimate intention is to avoid boilerplate code that validates
> every
> > >> single instance of `Duration` in the codebase. I'd rather have a class
> > with
> > >> guarantees certain invariants.
> > >>
> > >> [1]
> > https://internals.rust-lang.org/t/unsigned-version-of-duration/893/2
> > >>
> >
> >
>
--
Best Regards,
Haosdent Huang
