mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Budnik <abud...@mesosphere.io>
Subject Re: On fixing the FUTURE_DISPATCH macro
Date Wed, 07 Jun 2017 13:41:08 GMT
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 <mpark@apache.org> 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 <abudnik@mesosphere.io>
> 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
> >
>

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