> On Aug. 17, 2015, 11:01 p.m., Ben Mahler wrote: > > In the same vein as os::shell, we should probably introduce an 'os' > > namespace in libprocess for asynchronous os utilities. In this case, > > process::os::shell which returns a Future of the output (although, ideally > > <status, output, error>).
Sounds good. If I understand this correctly, the `process::os::shell` would take advantage of this refactoring, correct? (also, how about returning a `Future<CommandResult>`: this has all of <status, output, error> and a bit more). Could you please take a look at the next revision I'm about to post: it now all works and passes the tests, but I'm somewhat confused as to why the `onFailed` never got called and another nit - they are marked as FIXME(marco) and will be obviously removed - I needed a way to mark those areas visibly: they are not TODOs). Thanks! - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37336/#review95658 ----------------------------------------------------------- On Aug. 15, 2015, 2:02 a.m., Marco Massenzio wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/37336/ > ----------------------------------------------------------- > > (Updated Aug. 15, 2015, 2:02 a.m.) > > > Review request for mesos and Joris Van Remoortere. > > > Bugs: MESOS-3035 > https://issues.apache.org/jira/browse/MESOS-3035 > > > Repository: mesos > > > Description > ------- > > Jira: MESOS-3035 > > The original API for `process::Subprocess` still left a lot of legwork > to do for the caller; we have now added a `wait(Duration timeout)` method > that returns a `CommandResult` (also introduced with this patch) which > contains useful information about the command invocation; the exit code; > stdout and, optionally, stderr too. > > The `wait()` method will wait for both the process to terminate, and > stdout/stderr to be available to read from; it also "unpacks" them into > ready-to-use `string`s. > > This is still WIP as I'm seeing some unusual behavior and I'd like to discuss > with someone more expert on libprocess. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/subprocess.hpp > 310cb4f8e4e2faa5545dffd196d7490c868bc5d6 > 3rdparty/libprocess/src/subprocess.cpp > d6ea62ed1c914d34e0e189395831c86fff8aac22 > 3rdparty/libprocess/src/tests/subprocess_tests.cpp > ab7515325e5db0a4fd222bb982f51243d7b7e39d > > Diff: https://reviews.apache.org/r/37336/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Marco Massenzio > >
