Re: Review Request 61148: Added Future::recover.

[Benjamin Mahler]

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


Fix it, then Ship it!





3rdparty/libprocess/include/process/future.hpp
Lines 436-437 (patched)


Any TODOs needed here to treat abandonment the same across recover and 
onAny? It seems a little inconsistent that onAny wouldn't be triggered for all 
cases that recover gets triggered.



3rdparty/libprocess/include/process/future.hpp
Lines 1574-1584 (patched)


Just curious if you have any thoughts here on using set vs associate across 
these, it was a little confusing that they are aliases.

Is it that we have to use set when calling f because f may return a `T` 
instead of `Future`?


- Benjamin Mahler


On July 27, 2017, 1:55 a.m., Benjamin Hindman wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61148/
> ---
> 
> (Updated July 27, 2017, 1:55 a.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added Future::recover.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/future.hpp 
> cce950509f58022e79bb51a6e72ea1a005b9cb50 
>   3rdparty/libprocess/src/tests/future_tests.cpp 
> 0c8725b9a5e64aaac6e3979e450a11e84f9bd45e 
> 
> 
> Diff: https://reviews.apache.org/r/61148/diff/1/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Review Request 61148: Added Future::recover.

[Benjamin Hindman]

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

Review request for mesos and Benjamin Mahler.


Repository: mesos


Description
---

Added Future::recover.


Diffs
-

  3rdparty/libprocess/include/process/future.hpp 
cce950509f58022e79bb51a6e72ea1a005b9cb50 
  3rdparty/libprocess/src/tests/future_tests.cpp 
0c8725b9a5e64aaac6e3979e450a11e84f9bd45e 


Diff: https://reviews.apache.org/r/61148/diff/1/


Testing
---

make check


Thanks,

Benjamin Hindman