Hey Michael, The example of flaky test is provided in [1]. Andrei [1] https://gist.github.com/abudnik/242026538f9e4d6861e0b51408618161
On Sun, Jun 4, 2017 at 12:22 AM, Michael Park <[email protected]> wrote: > This sounds good to me in principle. Could you explain why it leads to > *flaky* tests? I only vaguely remember the issues here... > > On Fri, Jun 2, 2017 at 7:05 AM Andrei Budnik <[email protected]> > wrote: > > > MESOS-5886 > > > > > > > > Problem description: > > > > Using FUTURE_DISPATCH might lead to flakiness or errors in tests. > > FUTURE_DISPATCH > > < > > https://github.com/apache/mesos/blob/e8ebbe5fe4189ef7ab046da2276a6a > bee41deeb2/3rdparty/libprocess/include/process/gmock.hpp#L50 > > > > > uses DispatchMatcher > > < > > https://github.com/apache/mesos/blob/e8ebbe5fe4189ef7ab046da2276a6a > bee41deeb2/3rdparty/libprocess/include/process/gmock.hpp#L350 > > > > > 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). > > > > > > > > A little bit of history on the issue. > > > > > > > > Initial implementation of DispatchMatcher used stringified version of > > pointer-to-member function — it’s just the same thing as comparing by > value > > two pointer-to-member functions, which, in essence, means comparison of > the > > virtual offsets in vtable or comparison of function addresses. This > > approach has an issue: if two independent classes C1 and C2 have virtual > > functions with the same vtable offsets, then DispatchMatcher might match > > them as same functions under specific conditions (see > > https://reviews.apache.org/r/28052/). > > > > > > > > To address the aforementioned problem (MESOS-2112), it has been decided > to > > use type_info instead of function pointers for function matching. > type_info > > for class methods includes information about function signature, related > > class name and class namespace. However, type_info is not enough to > > uniquely identify two different methods with same signature. AlexR > > described a simple test that reproduces the bug in MESOS-5886. > > > > > > > > Michael Park proposed a solution in > > https://reviews.apache.org/r/28052/#comment106033: > > <https://reviews.apache.org/r/28052/#comment106033>keeping both > type_info > > and value of pointer-to-member function in DispatchEvent allows us to > > uniquely identify class methods. > > > > > > > > We plan to follow MPark’s suggestion and additionally store > > pointer-to-member function in DispatchEvent. This will increase the > memory > > footprint of actors’ mailboxes, which is an acceptable consequence in our > > opinion. > > > > > > > > Looking forward to comments and suggestions on the proposed change, > > > > Andrei > > >
