-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20339/#review40841
-----------------------------------------------------------


One tricky thing here is that the unit is implicit:

Timer t("read");

Now, we're exposing "read/..." with implicit units of nanoseconds. Anyone 
looking at the JSON will have a hard time figuring out what these values mean.

Would it be better to implicitly append a unit (like "_secs") and expose 
seconds? Or, should we overload Timer constructors to take in different 
Duration subclasses to allow callers to customize the time units?


3rdparty/libprocess/include/process/metrics/timer.hpp
<https://reviews.apache.org/r/20339/#comment74057>

    Did you miss this one for adding braces?



3rdparty/libprocess/include/process/metrics/timer.hpp
<https://reviews.apache.org/r/20339/#comment74058>

    Yikes, in these blocks let's try not to release the lock. You can do this 
by storing a Try<Nothing> result at the top and assigning it accordingly in the 
locked section. Ditto below.


- Ben Mahler


On April 19, 2014, 12:47 a.m., Dominic Hamon wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20339/
> -----------------------------------------------------------
> 
> (Updated April 19, 2014, 12:47 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ben Mahler.
> 
> 
> Bugs: MESOS-1217
>     https://issues.apache.org/jira/browse/MESOS-1217
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> see summary.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/Makefile.am d707ad759dacd16e0177e14f1bf5ece9e4ce2491 
>   3rdparty/libprocess/include/process/metrics/timer.hpp PRE-CREATION 
>   3rdparty/libprocess/src/tests/metrics_tests.cpp 
> abe1588c931b45a09294812974788aa74de44dd4 
> 
> Diff: https://reviews.apache.org/r/20339/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Reply via email to