MESOS-5886
Problem description: Using FUTURE_DISPATCH might lead to flakiness or errors in tests. FUTURE_DISPATCH <https://github.com/apache/mesos/blob/e8ebbe5fe4189ef7ab046da2276a6abee41deeb2/3rdparty/libprocess/include/process/gmock.hpp#L50> uses DispatchMatcher <https://github.com/apache/mesos/blob/e8ebbe5fe4189ef7ab046da2276a6abee41deeb2/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
