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



src/tests/cgroups_tests.cpp
<https://reviews.apache.org/r/7001/#comment25091>

    use the same style (one arg per line) as you did in the rest of the file 
and in configurator_tests



src/tests/cgroups_tests.cpp
<https://reviews.apache.org/r/7001/#comment25092>

    ditto



third_party/libprocess/include/stout/os.hpp
<https://reviews.apache.org/r/7001/#comment25126>

    from the man page, i'm not sure when NULL happens but errno is not equal to 
0.
    
    i think you should always return error if tree == NULL.
    
    This makes the return value of rmdir to be Try<Nothing> instead of 
Try<bool>.
    
    I like Try<Nothin> because its symmetrical with mkdir.



third_party/libprocess/include/stout/os.hpp
<https://reviews.apache.org/r/7001/#comment25127>

    again, similar to mkdir you should do 
    
    if (::rmdir() < 0 && errno != ENOENT) {..}
    
    this way removing non-existent files/directories is not an error.



third_party/libprocess/include/stout/os.hpp
<https://reviews.apache.org/r/7001/#comment25128>

    ditto


- Vinod Kone


On Sept. 15, 2012, 3:16 a.m., Ben Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/7001/
> -----------------------------------------------------------
> 
> (Updated Sept. 15, 2012, 3:16 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Vinod Kone, and Jie Yu.
> 
> 
> Description
> -------
> 
> We unnecessarily have Try<bool>s all over the place, these are tri-state: 
> {error, some:true, some:false}. It seems most cases, we never use 
> {some:false} in the function or the caller.
> 
> So, this restores some sanity to use two-state Try<void>s: {error, some}
> 
> 
> Diffs
> -----
> 
>   src/linux/cgroups.hpp 1a3cdc2 
>   src/linux/cgroups.cpp 53d611f 
>   src/linux/fs.hpp 31a6100 
>   src/linux/fs.cpp 744aea6 
>   src/log/replica.cpp 2bba6fc 
>   src/logging/logging.cpp d6d31ec 
>   src/slave/cgroups_isolation_module.hpp 00255b5 
>   src/slave/cgroups_isolation_module.cpp 34db9af 
>   src/slave/gc.hpp 3760d09 
>   src/slave/gc.cpp 5212a41 
>   src/slave/process_based_isolation_module.cpp c0576bd 
>   src/slave/slave.cpp 4ea1db1 
>   src/tests/cgroups_tests.cpp fbaa046 
>   src/tests/configurator_tests.cpp 8baed76 
>   src/tests/files_tests.cpp 6ef2004 
>   src/tests/stout_tests.cpp f690fac 
>   src/tests/zookeeper_server.hpp 4f34910 
>   src/webui/webui.cpp d4f2ab9 
>   third_party/libprocess/include/stout/os.hpp d08b0cb 
>   third_party/libprocess/include/stout/try.hpp ec0a7b6 
>   third_party/libprocess/src/process.cpp 2d2b56c 
> 
> Diff: https://reviews.apache.org/r/7001/diff/
> 
> 
> Testing
> -------
> 
> osx 10.7 gcc 4.2.1
> redhat Red Hat 4.1.2-48 gcc 4.1.2
> 
> make
> make check
> 
> note that SampleFrameworks.PythonFramework is consistently failing on red 
> hat, unrelated to this change
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Reply via email to