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

Ship it!



3rdparty/libprocess/src/io.cpp (line 267)
<https://reviews.apache.org/r/36404/#comment152509>

    We might as well move this to just before it's really needed and just 
'return Failure();' before that as we do in some cases but not all cases.



3rdparty/libprocess/src/io.cpp (lines 298 - 310)
<https://reviews.apache.org/r/36404/#comment152508>

    Rather than check the file descriptor, we might as well just make the 
dup'ed file descriptor to be non-blocking, since it doesn't change the original 
discriptor we we know we want it to be non-blocking because we're going to call 
'internal::read' which we don't want to block on the first 'recv' call!



3rdparty/libprocess/src/tests/io_tests.cpp (lines 376 - 377)
<https://reviews.apache.org/r/36404/#comment152510>

    Can kill this now.


- Benjamin Hindman


On Aug. 27, 2015, 4:24 p.m., Artem Harutyunyan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36404/
> -----------------------------------------------------------
> 
> (Updated Aug. 27, 2015, 4:24 p.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Joseph Wu.
> 
> 
> Bugs: MESOS-2964
>     https://issues.apache.org/jira/browse/MESOS-2964
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/io.hpp 
> 975923f40f82357f31b89428f24d01df6a8ac9fc 
>   3rdparty/libprocess/src/io.cpp 4a6e18a17012994d358099ad32d4c282fea3b0b1 
>   3rdparty/libprocess/src/tests/io_tests.cpp 
> c642b3333ab9e2845668767ad237985cb9ce1109 
> 
> Diff: https://reviews.apache.org/r/36404/diff/
> 
> 
> Testing
> -------
> 
> - Added a test case for process::io::peek
> - make check
> 
> 
> Thanks,
> 
> Artem Harutyunyan
> 
>

Reply via email to