> On Aug. 22, 2012, 2:18 a.m., Jie Yu wrote:
> >
> 
> Jie Yu wrote:
>     Ben, I don't quite understand get you 'TODO' in io::read. Why can't we 
> reuse that for http::get()?

io::read performs a single non-blocking read on the socket into an external 
buffer of fixed size

with get() I need to read a response of unknown size, until I get a completed 
HttpResponse or the socket is closed, etc.
this means in order to re-use io::read I will either have to write my own 
variant (i.e. not re-use it), or try to loop through io::read with futures.. I 
had trouble wiring the latter up =/

But I'll probably have another go at it today now that my brain is fresh :)


> On Aug. 22, 2012, 2:18 a.m., Jie Yu wrote:
> > third_party/libprocess/src/process.cpp, line 3175
> > <https://reviews.apache.org/r/6617/diff/3/?file=143754#file143754line3175>
> >
> >     This function actually blocks on recv(). This will block a libprocess 
> > worker thread. That makes me feel that we should never use this function 
> > except in tests.

yes I know, as I said in the publish comments, this first is a blocking get, 
and I'll be re-publishing with a non-blocking get afterwards, this review was 
mostly for the rest of the code


> On Aug. 22, 2012, 2:18 a.m., Jie Yu wrote:
> > third_party/libprocess/src/process.cpp, line 3179
> > <https://reviews.apache.org/r/6617/diff/3/?file=143754#file143754line3179>
> >
> >     Since you pass flags '0' to recv, I don't think you can get these two 
> > errno.
> >     
> >     You should specify MSG_DONTWAIT when calling recv().
> >     
> >     Also, see my above comment.

alright, I guess that's fine, but it's redundant since I have O_NONBLOCK (I've 
commented that part out, since this was the blocking version for now).

"Enables nonblocking operation; if the operation would block, the call fails 
with the error EAGAIN or EWOULDBLOCK (this can also be enabled using the 
O_NONBLOCK flag with the F_SETFL fcntl(2))."


- Ben


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


On Aug. 22, 2012, 1:37 a.m., Ben Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6617/
> -----------------------------------------------------------
> 
> (Updated Aug. 22, 2012, 1:37 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Vinod Kone, and Jie Yu.
> 
> 
> Description
> -------
> 
> Implementing the file abstraction and http endpoints for file reading / 
> browsing.
> 
> 
> This addresses bug MESOS-255.
>     https://issues.apache.org/jira/browse/MESOS-255
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am aaceee3 
>   src/files/files.hpp d0cab91 
>   src/files/files.cpp d4080d4 
>   src/logging/logging.cpp 6909b0b 
>   src/master/http.cpp c480bc6 
>   src/master/slaves_manager.cpp e25efd0 
>   src/slave/http.cpp a1f7926 
>   src/tests/configurator_tests.cpp c2f5aa0 
>   src/tests/files_tests.cpp PRE-CREATION 
>   src/tests/utils.hpp 83d5daa 
>   src/webui/master/static/controllers.js 1606e64 
>   third_party/libprocess/include/process/http.hpp 8424ca6 
>   third_party/libprocess/include/process/io.hpp 6a40b18 
>   third_party/libprocess/include/stout/hashmap.hpp 51bdea0 
>   third_party/libprocess/include/stout/json.hpp 25dbcf4 
>   third_party/libprocess/include/stout/os.hpp b1eceb3 
>   third_party/libprocess/include/stout/path.hpp 80d9bc6 
>   third_party/libprocess/include/stout/stringify.hpp ad2f2fa 
>   third_party/libprocess/src/decoder.hpp 105fe5d 
>   third_party/libprocess/src/encoder.hpp ac4886e 
>   third_party/libprocess/src/process.cpp 78069bf 
>   third_party/libprocess/src/statistics.cpp d05b327 
> 
> Diff: https://reviews.apache.org/r/6617/diff/
> 
> 
> Testing
> -------
> 
> Added files_tests.cpp
> make check
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Reply via email to