mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Budnik <abud...@mesosphere.com>
Subject Re: Review Request 60008: Fixed bug causing FUTURE_DISPATCH to react on irrelevant dispatch.
Date Wed, 28 Jun 2017 14:56:43 GMT


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message