----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61150/#review181765 -----------------------------------------------------------
Fix it, then Ship it! I'm hoping we can update abandonment to trigger onAny before we start writing a lot of abandonment handling code that has recover + onAny instead of just onAny. 3rdparty/libprocess/include/process/collect.hpp Line 79 (original), 79 (patched) <https://reviews.apache.org/r/61150/#comment257466> Whoops, as an aside, I think we wanted this as protected. 3rdparty/libprocess/include/process/collect.hpp Lines 167-173 (patched) <https://reviews.apache.org/r/61150/#comment257467> It would be great to have a TODO on the public interface to say that ideally, onAny is triggered on abandonment and the caller doesn't get the entire result abandoned if one underlying future is abandoned. The implementation you have here doesn't seem like the intended use of await IMO, but I realize you're just trying to match the onAny semantics. :( - 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/61150/ > ----------------------------------------------------------- > > (Updated July 27, 2017, 1:55 a.m.) > > > Review request for mesos and Benjamin Mahler. > > > Repository: mesos > > > Description > ------- > > Added Future::onAbandoned semantics to process::collect/await. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/collect.hpp > fccf55a26a2ef61fa3b73d100a0741832e4dfa56 > 3rdparty/libprocess/src/tests/collect_tests.cpp > 155e0bb75cf723a0a6c29020f9f767e3ba3d7401 > > > Diff: https://reviews.apache.org/r/61150/diff/1/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Hindman > >