> On March 10, 2014, 4:47 p.m., Dominic Hamon wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 17 > > <https://reviews.apache.org/r/18954/diff/1/?file=514953#file514953line17> > > > > i know it doesn't match the include order, but it might be more > > maintainable as we move towards C++11 to put this as the #else stanza above.
I'm going to keep the include ordering for now as it should be easier to clean this up after we move to C++11. > On March 10, 2014, 4:47 p.m., Dominic Hamon wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 469 > > <https://reviews.apache.org/r/18954/diff/1/?file=514953#file514953line469> > > > > is the callback responsible for checking the future then? would it be > > better to avoid calling the callback if the future has been discarded to > > avoid boilerplate/mistakes? There is a race between when we might make that check and when the callback gets invoked and during that race the future might indeed become discarded which means that the callback given in Future::after must _always_ check if the future has been discarded. Rather than possibly hiding a non-deterministic bug we always call the callback regardless of whether or not the future has been discarded. I've added a comment that says as much. > On March 10, 2014, 4:47 p.m., Dominic Hamon wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 483 > > <https://reviews.apache.org/r/18954/diff/1/?file=514953#file514953line483> > > > > you could use lambda::function in both the C++11 and boost cases to > > make future cleanup easier. In the future we'd then want to switch back from lambda::function to std::function so that seems it would just make cleanup harder! - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18954/#review36659 ----------------------------------------------------------- On March 10, 2014, 6:13 p.m., Benjamin Hindman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18954/ > ----------------------------------------------------------- > > (Updated March 10, 2014, 6:13 p.m.) > > > Review request for mesos, Ben Mahler, Jie Yu, and Vinod Kone. > > > Repository: mesos-git > > > Description > ------- > > This is to avoid a standard pattern seen with doing a 'delay' after some > asynchronous function call has been made and we're waiting on it's completion > via Future::then, onAny, etc. This allows one to do: > > someAsynchronousFunction() > .then(defer(self(), &Self::_continuation1)) > .then(defer(self(), &Self::_continuation2)) > .after(Seconds(30), defer(self(), &Self::_timeout, lambda::_1)); > > > Diffs > ----- > > 3rdparty/libprocess/include/process/future.hpp > 27b0970bf1d1ae1b977ddfc2de5ee858f1031bf5 > 3rdparty/libprocess/include/process/http.hpp > 7f549ba3476ecf5dec0db21d57ee58bcd73d5996 > 3rdparty/libprocess/src/tests/process_tests.cpp > e899aed7dbe6e8645484fe0ba69521e9fb0fdad2 > > Diff: https://reviews.apache.org/r/18954/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Hindman > >
