> On July 9, 2013, 6:22 a.m., Benjamin Hindman wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp, line 76 > > <https://reviews.apache.org/r/12146/diff/1/?file=312848#file312848line76> > > > > How can a signal in this threads signal queue be delivered to another > > thread? Have you seen this in practice?
See 2.4.1 here: http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html Notably: "Signals generated for the process shall be delivered to exactly one of those threads within the process which is in a call to a sigwait() function selecting that signal or has not blocked delivery of the signal. If there are no threads in a call to a sigwait() function selecting that signal, and if all threads within the process block delivery of the signal, the signal shall remain pending on the process until a thread calls a sigwait() function selecting that signal, a thread unblocks delivery of the signal, or the action associated with the signal is set to ignore the signal." Beefed up the comment to point to this page. > On July 9, 2013, 6:22 a.m., Benjamin Hindman wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/sendfile.hpp, lines > > 127-128 > > <https://reviews.apache.org/r/12146/diff/1/?file=312848#file312848line127> > > > > The implication here is that callers will actually want to look at > > errno after calling os::sendfile. We have discussed these semantics in the > > past, but this would be (to the best of my knowledge) the first real > > function that returns a Try where we preserve the errno semantics and > > expect people to use them. So: why return a Try at all? Or why not just use > > 'suppress(SIGPIPE) {' directly where we currently call ::sendfile and > > already are properly handling all the errors? Partially fixed this one, I removed the Try to force the caller to treat this with -1 error semantics. However, I do like the idea of providing a sendfile wrapper (if you look at what we had in 3rdparty/libprocess/src/config.hpp it's made generic with a macro and is only usable by libprocess). - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12146/#review22845 ----------------------------------------------------------- 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 > >
