mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cody Maloney" <c...@mesosphere.io>
Subject Re: Review Request 28052: Match future dispatch messages with type info.
Date Mon, 01 Dec 2014 22:41:36 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28052/#review63451
-----------------------------------------------------------



3rdparty/libprocess/include/process/gmock.hpp
<https://reviews.apache.org/r/28052/#comment105706>

    The type_info::name() is (on linux, x86_64 using the standard ABI) defined to be the symbol
name.
    
    See: https://mentorembedded.github.io/cxx-abi/abi.html#typeid
    
    Other platforms don't have the same ABI spec though.


- Cody Maloney


On Nov. 20, 2014, 9 a.m., Timothy Chen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28052/
> -----------------------------------------------------------
> 
> (Updated Nov. 20, 2014, 9 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-2112
>     https://issues.apache.org/jira/browse/MESOS-2112
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> The fix in this rb is to instead of matching pointer values, but to compare type_info
from the member function pointers passed in. This ensures we're matching the same method.
> 	 	
> 	 	
> The downside of this approach is that, we no longer can do the following in tests:	 

> 	 	
> class A : ProcessBase<A> {
> public:
>   virtual void foo() {};
> };
> 	 		 	
> class B : public A {
> public:
>   virtual void foo() {};
> };
> 	 	
> Future<Nothing> future = FUTURE_DISPATCH(_, &B::foo);
> 	 	
> process.dispatch(B.self(), &A::foo);
> 	 	
> AWAIT_READY(future);
> 	 	
> We no longer can match the future on a derived method, but on dispatch passing the base
member function pointer. This only used to work since the virtual offsets of both is matching
the same address, but arguable is not the right behavior since the reverse is a false positive
but will also match. We've done this in a few places in tests around the AllocatorProcess.
> 
> Review: https://reviews.apache.org/r/28052
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/c++11/dispatch.hpp 76da2828cf36b6143d627dac66f3e0cc4416bae4

>   3rdparty/libprocess/include/process/dispatch.hpp bceda2a2ae8963921e8e19660243a8644feab227

>   3rdparty/libprocess/include/process/event.hpp 294e2158876b25b06456a3619e547082d71e31ed

>   3rdparty/libprocess/include/process/gmock.hpp d6f2fc8fef8acd1498a36c86e09b28d986eefa15

>   3rdparty/libprocess/src/process.cpp 7a986d7defb03043ec70a48e161ede50deef9b26 
> 
> Diff: https://reviews.apache.org/r/28052/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>


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