> On June 17, 2014, 9:43 p.m., Benjamin Hindman wrote:
> > 3rdparty/libprocess/src/subprocess.cpp, line 250
> > <https://reviews.apache.org/r/22688/diff/2/?file=611764#file611764line250>
> >
> >     With dup'ed file descriptors you can kill this check.
> 
> Jie Yu wrote:
>     Ben, I still prefer to having this check here even if we dup'ed the fd. 
> The reason is because: what if the parent has a closed stdin/stdout/stderr, 
> when calling ::dup, the returned file descriptor is gonna be one of them 
> (stdin/stdout/stderr). And this can cause the stdin/stdout/stderr file 
> descriptor of the subprocess to be closed , which is not what we wanted?
>     
>     What do you think?

Ah yes, I agree: we'll always do the dup there but we only want to close if 
it's not STDIN_FILENO.


- Benjamin


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


On June 17, 2014, 6:51 p.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22688/
> -----------------------------------------------------------
> 
> (Updated June 17, 2014, 6:51 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone.
> 
> 
> Bugs: MESOS-1487
>     https://issues.apache.org/jira/browse/MESOS-1487
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> See summary.
> 
> This patch only updates the references in libprocess. The update for mesos 
> will be submitted shortly.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/subprocess.hpp e9d7b31 
>   3rdparty/libprocess/src/subprocess.cpp 9f8f37f 
>   3rdparty/libprocess/src/tests/subprocess_tests.cpp 7d890bf 
> 
> Diff: https://reviews.apache.org/r/22688/diff/
> 
> 
> Testing
> -------
> 
> 3rdparty/libprocess/tests --gtest_repeat=100 --gtest_filter=*Subproces*
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Reply via email to