> On June 26, 2017, 2:15 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/include/process/dispatch.hpp
> > Lines 68 (patched)
> > <https://reviews.apache.org/r/60008/diff/1/?file=1748335#file1748335line68>
> >
> > Why don't you use `Option<>`?
Fixed.
> On June 26, 2017, 2:15 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/include/process/event.hpp
> > Lines 178-179 (patched)
> > <https://reviews.apache.org/r/60008/diff/1/?file=1748336#file1748336line178>
> >
> > Please a blank line here, i.e.,
> > ```
> > // Any society that would give up a little liberty to gain
> > // a little security will deserve neither and lose both.
> > //
> > // TODO(abudnik): Add a source link for the quote above.
> > ```
Fixed.
> On June 26, 2017, 2:15 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/tests/process_tests.cpp
> > Line 189 (original), 190-192 (patched)
> > <https://reviews.apache.org/r/60008/diff/1/?file=1748339#file1748339line190>
> >
> > We strive to add a descriptive comment for each test. Even though it is not
an easy to go and add comments to existing tests, we do want to have a proper description
for every newly added test.
Done.
> On June 26, 2017, 2:15 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/tests/process_tests.cpp
> > Lines 204-205 (patched)
> > <https://reviews.apache.org/r/60008/diff/1/?file=1748339#file1748339line204>
> >
> > Why do you need this statement?
This declares expectations about test behaviour. See next test THREADSAFE_Defer1 which uses
EXPECT_CALL as well.
> On June 26, 2017, 2:15 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/tests/process_tests.cpp
> > Lines 208-209 (patched)
> > <https://reviews.apache.org/r/60008/diff/1/?file=1748339#file1748339line208>
> >
> > Additionally to (or actually instead of) `EXPECT` here, `AWAIT_READY(f);` would
carry your intent better, I think. I would actually get rid of call expectations all together
and simply focus on future states.
Fixed.
- Andrei
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60008/#review178888
-----------------------------------------------------------
On June 28, 2017, 2:56 p.m., Andrei Budnik wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60008/
> -----------------------------------------------------------
>
> (Updated June 28, 2017, 2:56 p.m.)
>
>
> Review request for mesos, Alexander Rukletsov, Michael Park, and Neil Conway.
>
>
> Bugs: MESOS-5886
> https://issues.apache.org/jira/browse/MESOS-5886
>
>
> Repository: mesos
>
>
> Description
> -------
>
> FUTURE_DISPATCH uses DispatchMatcher to figure out whether a processed
> DispatchEvent is the same the user is waiting for. Currently, we
> compare std::type_info of function pointers, which is not enough:
> different class methods with same signatures will be matched (see
> MESOS-5886 for an example).
> This patch adds value of pointer-to-member function in addition to
> std::type_info in DispatchEvent to uniquely identify class methods.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/include/process/dispatch.hpp 3a0793888dc0df5e3ec31b06f47cd920c71e0db9
> 3rdparty/libprocess/include/process/event.hpp 8afe6266eb0dc5a17af35d79efb6bfdf9e6a0ee9
> 3rdparty/libprocess/include/process/gmock.hpp e9af943b39436f365fe687301febb5c7fbefffc4
> 3rdparty/libprocess/src/process.cpp 8ff37d1b5781c42f96be2da391ed000158eea7b8
> 3rdparty/libprocess/src/tests/process_tests.cpp 38d787a083a5eb31e922d283f4b4bed2bd62eb0a
>
>
> Diff: https://reviews.apache.org/r/60008/diff/2/
>
>
> Testing
> -------
>
> 1. make check (mac os x 10.12, fedora 25)
> 2. internal CI
>
> NOTE: Test GroupTest.ConnectTimer is broken, because it uses FUTURE_DISPATCH on a wrong
method (GroupProcess::expired),
> which has the same signature as a private method (GroupProcess::timedout). The later
method is actually called,
> thus causing the error after applying this patch.
>
>
> Thanks,
>
> Andrei Budnik
>
>
|