> 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 > >
