> On Jan. 15, 2019, 7:22 p.m., Benjamin Mahler wrote: > > Should we be surfacing a close EINTR as an error or let that be silent? > > I think these errors need some message pre-fixing? E.g. > > > > ``` > > Failed to close '3': Bad file number > > ``` > > > > As it stands the error messages will only show "Bad file number" and it > > won't be clear if the write or close produced this? It's also an issue here > > between open/write/flush but would be great to resolve this now.
If I read the POSIX spec for `close` correctly, if `close` fails with `EINTR` the passed file descriptor is left in an unspecified state so it e.g., would not be safe to assume that pending data was successfully flushed. Am I missing something? > On Jan. 15, 2019, 7:22 p.m., Benjamin Mahler wrote: > > 3rdparty/stout/include/stout/os/write.hpp > > Line 129 (original), 129 (patched) > > <https://reviews.apache.org/r/69082/diff/2/?file=2114349#file2114349line129> > > > > Looks to me like s/result/write would read better? > > > > ``` > > Try<Nothing> write = os::write(fd.get(), message); > > > > ... > > > > Try<Nothing> close = os::close(fd.get()); > > > > // Propagate `close` errors if `write` succeeded. > > if (close.isError() && !write.isError()) { > > return close; > > } > > > > return write; > > ``` > > > > Ditto for the others Good idea. Like you showed in your example this requires some name disambiguation, but ultimately reads better. > On Jan. 15, 2019, 7:22 p.m., Benjamin Mahler wrote: > > 3rdparty/stout/include/stout/os/write.hpp > > Line 140 (original), 140 (patched) > > <https://reviews.apache.org/r/69082/diff/2/?file=2114349#file2114349line140> > > > > newline above this to be consistent with the rest of the formatting in > > this function? ditto for the others Went with freestanding calls to `close`. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/69082/#review212026 ----------------------------------------------------------- On Jan. 16, 2019, 2:06 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/69082/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2019, 2:06 p.m.) > > > Review request for mesos, Benjamin Mahler, Chun-Hung Hsiao, and Alex Clemmer. > > > Bugs: MESOS-9331 > https://issues.apache.org/jira/browse/MESOS-9331 > > > Repository: mesos > > > Description > ------- > > When e.g., writing to disk, errors from write might only manifest at > ::close time. We update some instances to correctly propagate these > errors instead of dropping them silently. We only propagate the > ::close error if the write operation succeeded, otherwise we just > propagate the error from the write operation. > > > Diffs > ----- > > 3rdparty/stout/include/stout/os/posix/mktemp.hpp > 63b3d1a7720d07f877fa1d4eb7f32a548916637a > 3rdparty/stout/include/stout/os/write.hpp > f7538f94f5a953a7a90a05bc1d2f138b6c17f814 > 3rdparty/stout/include/stout/protobuf.hpp > eb4adef56f1701e3c101284e05e4e6c66eef9180 > > > Diff: https://reviews.apache.org/r/69082/diff/3/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
