You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Joris Van Remoortere <jo...@gmail.com> on 2015/10/12 18:08:45 UTC
Re: Review Request 37336: Simplified the caller interface to
process::Subprocess
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37336/#review102243
-----------------------------------------------------------
3rdparty/libprocess/include/process/subprocess.hpp (line 68)
<https://reviews.apache.org/r/37336/#comment159812>
`{` on new line
3rdparty/libprocess/include/process/subprocess.hpp (line 94)
<https://reviews.apache.org/r/37336/#comment159813>
full words for variable names.
3rdparty/libprocess/include/process/subprocess.hpp (line 281)
<https://reviews.apache.org/r/37336/#comment159817>
Is this API something you agreed on with your shepherd? I'm curious why we provide a blocking function rather than returning a future with the provided timeout.
3rdparty/libprocess/include/process/subprocess.hpp (line 292)
<https://reviews.apache.org/r/37336/#comment159816>
If this value is not meaningful until wait is finished, why not make this a future bound by that condition rather than providing undefined behavior?
- Joris Van Remoortere
On Oct. 12, 2015, 12:29 p.m., Marco Massenzio wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37336/
> -----------------------------------------------------------
>
> (Updated Oct. 12, 2015, 12:29 p.m.)
>
>
> Review request for mesos, Joris Van Remoortere and Michael Park.
>
>
> 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.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/include/process/subprocess.hpp d2341a53aac7c779668ee80983f73158fd44bff5
> 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
>
>
Re: Review Request 37336: Simplified the caller interface to
process::Subprocess
Posted by Marco Massenzio <ma...@mesosphere.io>.
> On Oct. 12, 2015, 4:08 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/include/process/subprocess.hpp, line 281
> > <https://reviews.apache.org/r/37336/diff/6/?file=1044858#file1044858line281>
> >
> > Is this API something you agreed on with your shepherd? I'm curious why we provide a blocking function rather than returning a future with the provided timeout.
uhm... `wait()` is by definition blocking :)
following our conversation, I'm going to change the name (and the signature) to return a Future instead
> On Oct. 12, 2015, 4:08 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/include/process/subprocess.hpp, line 292
> > <https://reviews.apache.org/r/37336/diff/6/?file=1044858#file1044858line292>
> >
> > If this value is not meaningful until wait is finished, why not make this a future bound by that condition rather than providing undefined behavior?
With the new signature, yes this will change too.
BTW this is not "undefined" - it is created in a way that it makes sense even in the case of failures.
- Marco
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37336/#review102243
-----------------------------------------------------------
On Oct. 12, 2015, 12:29 p.m., Marco Massenzio wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37336/
> -----------------------------------------------------------
>
> (Updated Oct. 12, 2015, 12:29 p.m.)
>
>
> Review request for mesos, Joris Van Remoortere and Michael Park.
>
>
> 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.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/include/process/subprocess.hpp d2341a53aac7c779668ee80983f73158fd44bff5
> 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
>
>