mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Mahler" <benjamin.mah...@gmail.com>
Subject Review Request 13381: Added collect2 to return Futures instead of values.
Date Wed, 07 Aug 2013 18:31:04 GMT

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

Review request for mesos, Benjamin Hindman and Vinod Kone.


Repository: mesos-git


Description
-------

Throwing this up as a bit of a straw man proposal.

I have code upstream in a branch where I'd like to collect a set of futures, but I'd like
to process a partial result. That is, it is not a failure if any of the Futures fail or become
discarded. When this occurs, I would still like to process all of the Futures that were successful.

Simplified code below for using collect2:

{
  list<Future<ResourceStatistics> > futures;

  foreachkey (const FrameworkID& frameworkId, executors) {
    foreachkey (const ExecutorID& executorId, executors[frameworkId]) {
      futures.push_back(
          dispatch(isolator, &Isolator::usage, frameworkId, executorId));
    }
  }

  return process::collect2(futures)
    .then(lambda::bind(
        __statisticsJSON,
        lambda::_1));
}

Future<http::Response> __statisticsJSON(
    const list<Future<ResourceStatistics> >& statistics)
{
  foreach (const Future<ResourceStatistics>& stats, statistics) {
    // Ignore failed / discarded results, possibly log warnings.
    if (stats.isFailed() || stats.isDiscarded()) {
      continue;
    }
    
    CHECK(stats.isReady());

    // Process the statistics.
  }

  return http::OK(result, jsonp);
}

One approach is to create a collect2 as above, which returns once all the Futures have transitioned
states. If we go with this approach, what are appropriates names instead of collect2?

Alternatively, I could have my code iteratively retry until it gets a successful collect()
result. However, it requires a guard against infinite retries.

Thoughts?


Diffs
-----

  3rdparty/libprocess/include/process/collect.hpp 3c620aa7ab2af1a8348c1fb190cbf490a7cf1a60


Diff: https://reviews.apache.org/r/13381/diff/


Testing
-------

make check (I will add a test if we like this approach).


Thanks,

Ben Mahler


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