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



3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp
<https://reviews.apache.org/r/11848/#comment45170>

    Why? If the process does not exist, then the Try will be an error, also we 
don't log warnings in stout.



3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp
<https://reviews.apache.org/r/11848/#comment45172>

    Is there the need to check for zombie processes? The semantics of "alive" 
would suggest that zombies are not considered alive ;)
    
    I'd be happy to add another function should we require different semantics 
at some point, but it seems at the moment we simply want an "alive"ness check?


- Ben Mahler


On June 12, 2013, 7:45 p.m., Ben Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11848/
> -----------------------------------------------------------
> 
> (Updated June 12, 2013, 7:45 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Vinod Kone, and Jiang Yan Xu.
> 
> 
> Description
> -------
> 
> os::alive currently considers zombie processes to be alive, which is less 
> than optimal, as semantically they are "dead" and waiting to be reaped.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
> 1b3fb47d7567b5467fef2a2bb15d5c4a2ea42aa5 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/linux.hpp PRE-CREATION 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/osx.hpp PRE-CREATION 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/process.hpp 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/11848/diff/
> 
> 
> Testing
> -------
> 
> This was tested through my killtree change, although it would be nice to have 
> tests once we have an abstraction for creating arbitrary process trees.
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Reply via email to