> 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
>
>
|