> On Feb. 2, 2018, 6:04 a.m., Benjamin Mahler wrote: > > Can you include Andy on this review as well? I would love to know what the > > suggested approach to this is; if there is some solution in place other > > than `#ifdef`s. > > Andrew Schwartzmeyer wrote: > Depending on how this error code is used later, we could probably do some > sort of mapping in > [`WindowsSocketError`](https://github.com/apache/mesos/blob/1600ebc6901239ae86e4e133c82d3424c56c978e/3rdparty/stout/include/stout/windows/error.hpp#L124) > (the underlying type of `SocketError` on Windows) so you can manually > construct it with `ENOTCONN` and its mapped to `WSAENOTCONN` on Windows. > Thing is, then we'd also need to make sure comparisons are done the same way. > Hm... > > Andrew Schwartzmeyer wrote: > A simpler approach may just be the latter half of that suggestion. If you > compare `WindowsSocketError` to `ENOTCONN`, have the comparator return `true` > if its type is either `ENOTCONN` (for a hard-code like this) or `WSAENOTCONN` > (from an actual OS error). > > Otherwise, I'd also suggest not returning `ENOTCONN` at all, since this > code is being a bit misleading about the state of the error. That is, I think > it's expected that `ENOTCONN` is only returned when an OS socket function > actually errors with `ENOTCONN`, and this error logic is our own case of > having never initialized. We could return our own error instead, that's the > same on both Linux and Windows (and BSD etc.).
I believe ENOTCONN is what will be returned in this case if we were to call shutdown on the fd: http://pubs.opengroup.org/onlinepubs/9699919799/functions/shutdown.html Either we can return this directly and avoid the syscall or we can directly call `::shutdown()` on the fd and return its error (which FWICT must be ENOTCONN). Both sound ok to me, but I would avoid making up a new error code. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/65475/#review196687 ----------------------------------------------------------- On Feb. 2, 2018, 5:50 a.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/65475/ > ----------------------------------------------------------- > > (Updated Feb. 2, 2018, 5:50 a.m.) > > > Review request for mesos, Andrew Schwartzmeyer, Benjamin Mahler, and Joseph > Wu. > > > Repository: mesos > > > Description > ------- > > see summary. > > > Diffs > ----- > > 3rdparty/libprocess/src/libevent_ssl_socket.cpp > 521b0cfbccd3599524b1407ef70880f4538941df > > > Diff: https://reviews.apache.org/r/65475/diff/1/ > > > Testing > ------- > > make check and internal CI > > > Thanks, > > Till Toenshoff > >
