----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12146/#review22674 -----------------------------------------------------------
3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46356> // __linux__ ? 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46358> s/pending/_pending/ ? to avoid shadowing the member variable. 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46360> No error checking? 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46367> I'm a bit confused. What is the difference between pending and blocked? Your comment above #39 seems to suggest pending => blocked? If yes, why do we need 'unblocked'? 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46359> Why do you have to do this? Probably needs some comments. 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46363> Did you mean to say.. "If the signal was generated before supression, we do nothing. Otherwise, if the signal was generated after supression, then we clear it." 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46366> Why do you need this? A comment perhaps? 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46364> const 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp <https://reviews.apache.org/r/12146/#comment46368> why the cast? 3rdparty/libprocess/3rdparty/stout/tests/os/sendfile_tests.cpp <https://reviews.apache.org/r/12146/#comment46370> How about subclassing TemporaryDirectoryTest? You can get rid of a lot of boiler plate below. 3rdparty/libprocess/3rdparty/stout/tests/os/sendfile_tests.cpp <https://reviews.apache.org/r/12146/#comment46372> new line 3rdparty/libprocess/3rdparty/stout/tests/os/sendfile_tests.cpp <https://reviews.apache.org/r/12146/#comment46375> Why on the heap? - Vinod Kone On June 28, 2013, 3:33 a.m., Ben Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12146/ > ----------------------------------------------------------- > > (Updated June 28, 2013, 3:33 a.m.) > > > Review request for mesos, Benjamin Hindman, Ian Downes, and Vinod Kone. > > > Bugs: MESOS-508 > https://issues.apache.org/jira/browse/MESOS-508 > > > Repository: mesos > > > Description > ------- > > This is to resolve MESOS-508 by masking SIGPIPE per-thread through a > "Suppressor" abstraction. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/Makefile.am > ade668846135bae9e977b65ce0ad0b72865cbf7a > 3rdparty/libprocess/3rdparty/stout/Makefile.am > 864b30ea5661cc7f613fdd422fe55f76fdafd1c1 > 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp > 429039644832470f7fd2eac19b213905cc81dcd3 > 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp > PRE-CREATION > 3rdparty/libprocess/3rdparty/stout/tests/os/sendfile_tests.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/12146/diff/ > > > Testing > ------- > > ./3rdparty/libprocess/3rdparty/stout-tests > --gtest_filter="OsSendfileTest.sendfile" --gtest_repeat=30000 > --gtest_break_on_failure > > > Thanks, > > Ben Mahler > >
