> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 243-249 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line243>
> >
> >     I think it is safe to use this function because it is only accessed 
> > from `MemoryProfiler::DiskArtifact::path()` which is in turn only accessed 
> > from `MemoryProfiler` methods, which are always serialized. You should call 
> > this in a comment or even employ `process::Once` now to make sure it is 
> > thread-safe and hence future-proof.
> 
> Benno Evers wrote:
>     I will add a comment. I think using `Once` can be counter-productive, 
> because the serialization provided by `libprocess` is fundamental enough that 
> most likely everything would break if it wouldn't exist - leading the reader 
> to wonder why it isn't enough in this function so that `Once` needs to be 
> used.

The reason I suggested to use `Once` is because this is a free function and it 
is not immediately clear that it is called only from a single actor instance.


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 264 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line264>
> >
> >     Say "using std::string" in the beginning of the file and save hundreds 
> > of characters!
> 
> Benno Evers wrote:
>     I'm not a fan of using `using`-directives just to save some typing, as it 
> puts a large cognitive burden on the reader: Is `string` referring to name 
> imported to the global namespace via `using`, a class-local or a 
> function-local typedef, maybe defined in some `stout`-header? In any case, 
> one has to jump to a different context to double-check. Using `std::string`, 
> on the other hand, is not ambigous.

```
alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "std::string" ./src | 
wc -l      
     465

alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "using std::string" 
./src | wc -l
     371
```
We have ~370 .cpp files with `using std::string` and \<100 mentions of 
`std::string`. We also do not provide our own string type; ambiguous local 
typedefs shall not be used.

In addition to the above, I personally find meaningless prefixes and 
characters, like `std::`, contributing to the cognitive load of the code.


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 630 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line630>
> >
> >     Use `profilingTimer->timeout().remaining()` directly.
> 
> Benno Evers wrote:
>     There are two issues with that:
>     1) The redirectTime is currently selected to be 2 seconds shorter than 
> the time remaining in the profiling timer, so by default it is the redirect 
> that is stopping the profiling
>     2) Aesthetically, if a user is selecting `duration=5secs` it seems odd to 
> display `You will be redirected in 4.99993 seconds`.

Re 2): You will have this case anyway if profiling is in progress when the 
request arrives; you can also round it up.

Re 1): I'm not sure I understand why you use this 2s delay.


- Alexander


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


On Feb. 6, 2018, 5:45 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63368/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2018, 5:45 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This class exposes profiling functionality of jemalloc memory allocator
> when it is detected to be the memory allocator of the current process.
> 
> In particular, it gives developers an easy method to collect and
> access heap profiles which report which pieces of code were
> responsible for allocating memory.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/Makefile.am 3071b7ce2b82a4ce0ea62e4d2b3518a6f5114803 
>   3rdparty/libprocess/include/process/memory_profiler.hpp PRE-CREATION 
>   3rdparty/libprocess/include/process/process.hpp 
> 8661706cb058efb26f5bfbcc84972f9930d3670f 
>   3rdparty/libprocess/src/CMakeLists.txt 
> f002c157dc2ca64da66bc4e61f5095f2b533ae1f 
>   3rdparty/libprocess/src/memory_profiler.cpp PRE-CREATION 
>   3rdparty/libprocess/src/process.cpp 
> ba9bc291bb6741e32b3a066fe90771311d21852a 
> 
> 
> Diff: https://reviews.apache.org/r/63368/diff/4/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>

Reply via email to