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

Ship it!



3rdparty/libprocess/src/subprocess.cpp (line 330)
<https://reviews.apache.org/r/35561/#comment140700>

    Aren't we leaking this one in the parent process?



3rdparty/libprocess/src/subprocess.cpp (line 333)
<https://reviews.apache.org/r/35561/#comment140693>

    Should we be using copies here instead?
    
    ```
    foreachpair (const string key, const string value, environment.get()) {
        ...
    }
    ```



3rdparty/libprocess/src/tests/subprocess_tests.cpp (line 756)
<https://reviews.apache.org/r/35561/#comment140692>

    I can see that Clock::pause is pretty much everywhere at the top of these 
tests. However, I find it not ideal. It should be right before the preparation 
of any arguments for, and the invocation of the subprocess. 
    
    In this particular test, I would put it after the preparation of the 
parent's environment.


- Till Toenshoff


On June 17, 2015, 2:28 p.m., Benjamin Hindman wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/35561/
> -----------------------------------------------------------
> 
> (Updated June 17, 2015, 2:28 p.m.)
> 
> 
> Review request for mesos and Till Toenshoff.
> 
> 
> Bugs: MESOS-2832
>     https://issues.apache.org/jira/browse/MESOS-2832
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/subprocess.hpp 
> 425b119e5eb122fa21c3e54fe070c7d553958f2c 
>   3rdparty/libprocess/src/subprocess.cpp 
> f41f5e2a34788e31749eb996c8ab38ea45989068 
>   3rdparty/libprocess/src/tests/subprocess_tests.cpp 
> b5cfc8d3daff489b332b6bfef2872cef9abecefe 
> 
> Diff: https://reviews.apache.org/r/35561/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Reply via email to