> On Nov. 8, 2017, 1:48 p.m., Benjamin Bannier wrote: > > 3rdparty/stout/include/stout/os/posix/socket.hpp > > Lines 74 (patched) > > <https://reviews.apache.org/r/63654/diff/1/?file=1884313#file1884313line74> > > > > I am not sure such a function is useful in general; maybe consider > > adding it just as a lambda into `socketpair`.
It is used in [r/63655](https://reviews.apache.org/r/63655/). It's occasionally convenient. > On Nov. 8, 2017, 1:48 p.m., Benjamin Bannier wrote: > > 3rdparty/stout/include/stout/os/posix/socket.hpp > > Lines 82 (patched) > > <https://reviews.apache.org/r/63654/diff/1/?file=1884313#file1884313line82> > > > > We have no idea at this point which `close` failed. > > > > It seems we want to `map` `close` over an iterable of `int_fd`, each > > possibly creating an `Error`, and then possibly reduce all errors into a > > single `Error`, e.g., > > > > // UNTESTED EXAMPLE. > > template <size_t N> > > Try<Nothing> close(const array<int_fd, N>& fds) > > { > > // Use stout's `close` to automatically capture errors. > > auto results = map(&close, fds); > > > > std::vector<Error> errors; > > foreach (auto&& result, results) { > > if (result.isError()) { > > errors.push_back(result.error()); > > } > > } > > > > if (errors.empty()) { > > return Nothing(); > > } else { > > return Error(strings::join("; ", errors)); > > } > > } > We have no idea at this point which close failed. Right. In almost all cases, the caller throws away the error from `close(2)`. I agree that preserving each error would be more correct, but prefer to err on the side of simlicity following the YAGNI principle. In your example, joining the `Errors` doesn't really help anything. How is it any better to get an error message of "Bad file descriptor; Bad file descriptor"? To make this really correct, you'd want to return an `array<Option<Error>, N>` or something, which is cumbersome (and YAGI) ;) > On Nov. 8, 2017, 1:48 p.m., Benjamin Bannier wrote: > > 3rdparty/stout/include/stout/os/posix/socket.hpp > > Lines 89 (patched) > > <https://reviews.apache.org/r/63654/diff/1/?file=1884313#file1884313line89> > > > > Does it make sense to return a `Try<array<int_fd, 2>>` here for > > consistency with `os::pipe`? Yes. > On Nov. 8, 2017, 1:48 p.m., Benjamin Bannier wrote: > > 3rdparty/stout/include/stout/os/posix/socket.hpp > > Lines 131-132 (patched) > > <https://reviews.apache.org/r/63654/diff/1/?file=1884313#file1884313line131> > > > > Does it make sense to include this setup into this function? This > > function does not invoke `send`. This is for consistency with [os::socket](https://github.com/apache/mesos/blob/master/3rdparty/stout/include/stout/os/socket.hpp#L31). - James ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/63654/#review190444 ----------------------------------------------------------- On Nov. 8, 2017, 1:12 a.m., James Peach wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/63654/ > ----------------------------------------------------------- > > (Updated Nov. 8, 2017, 1:12 a.m.) > > > Review request for mesos, Benjamin Bannier and Jie Yu. > > > Bugs: MESOS-8156 > https://issues.apache.org/jira/browse/MESOS-8156 > > > Repository: mesos > > > Description > ------- > > Added a `net::socketpair` helper to stout that deals with > automatically setting O_CLOEXEC and disabling SIGPIPE where > necessary. > > > Diffs > ----- > > 3rdparty/stout/include/stout/os/posix/socket.hpp > bab0b808f53abd1314a7d13fc0cba75e5717f96f > 3rdparty/stout/tests/os/sendfile_tests.cpp > 05966ae067ae3972598da3370eb16fdce5736c21 > > > Diff: https://reviews.apache.org/r/63654/diff/1/ > > > Testing > ------- > > make check (Fedora 26, macOS) > > > Thanks, > > James Peach > >
