----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5576/#review8655 -----------------------------------------------------------
third_party/libprocess/include/process/io.hpp <https://reviews.apache.org/r/5576/#comment18316> The problem with waiting until 'size' bytes are actually read is that in certain circumstances that could take a very long time indeed (forever). Consider this scenario: the file descriptor is actually for a socket, the socket is waiting for a message, but the user doesn't know if the message will be 10 bytes, or 100 bytes, or 1000 bytes, etc. So it allocates a buffer of size 1000 bytes, and performs a read. If the message is only 10 bytes, it would like to get that data immediately. The decision about whether to read more (up until 'size') should really be pushed to the user. I'd be fine with another version of read which doesn't return until a certain number of bytes have been read, but that version should be implemented on top of this version. - Benjamin Hindman On June 26, 2012, 4:19 p.m., Jie Yu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/5576/ > ----------------------------------------------------------- > > (Updated June 26, 2012, 4:19 p.m.) > > > Review request for mesos and Benjamin Hindman. > > > Description > ------- > > Provide an interface in process::io to do non-blocking read. It leverage the > io polling mechanism introduced in https://reviews.apache.org/r/5424/ > > > Diffs > ----- > > third_party/libprocess/include/process/io.hpp 801a6d5 > third_party/libprocess/src/process.cpp b7c181e > third_party/libprocess/src/tests.cpp 3d5005c > > Diff: https://reviews.apache.org/r/5576/diff/ > > > Testing > ------- > > cd /path/to/libprocess/build > ./tests > > Tested on both Mac and Linux. > > > Thanks, > > Jie Yu > >
