----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66437/ -----------------------------------------------------------
(Updated April 26, 2018, 9:17 p.m.) Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, and Michael Park. Changes ------- Please review again! * Added some `static_asserts` to document the underlying types. * Made the `HANDLE`, `SOCKET`, and `intptr_t` constructors `explicit`. * Added more commentary. * Ordered the functions according to the style guide. * Ran `clang-format` on the buffer. * Changed the stream output so it can be split on `=` easily. * Removed ordering operators between two `WindowsFD` types. * Marked the `std::hash` specialization as `noexcept`. * Return `std::hash` of the underlying types for consistency. * Explicitly constructed `int_fd` where now needed. Bugs: MESOS-8675 and MESOS-8683 https://issues.apache.org/jira/browse/MESOS-8675 https://issues.apache.org/jira/browse/MESOS-8683 Repository: mesos Description ------- After all the CRT APIs were replaced with Windows APIs, we no longer needed to support the semantics of an `int` file descriptor in general (in the sense of opening a CRT handle that's associated with the actual kernel object for the given `HANDLE`). There are specific use cases (usually third-party code) which still require a CRT int-like file descriptor, which the `crt()` function explicitly allocates (this allocation used to be done in the constructor). Thus the entire `FD_CRT` type was removed from the `WindowsFD` abstraction. It still acts like an `int` in the sense that it can be constructed from one and compared to one. However, construction via `int` only supports the standard file descriptors 0, 1, and 2 for `stdin`, `stdout`, and `stderr`. Any other construction creates an `int_fd` which holds an `INVALID_HANDLE_VALUE`. When being compared to an `int`, the abstraction simply returns -1 if it is invalid (based on the result of the `is_valid()` method) or 0 if it is valid. This is to support the semantics of checking validity by something like `if (fd < 0)` or `if (fd == -1)`. With the deletion of the `FD_CRT` type from `WindowsFD`, all the Stout APIs that switched on the type were simplified, with the last of the CRT code deleted. Thanks to the introduction of the private `int get_valid()` function, and the removal of the `FD_CRT` type, the comparison operators became much simpler. Several unit tests in the `FsTest` suite became cross-platform, with the `Close` test being simplified to test against an `int_fd`. Diffs (updated) ----- 3rdparty/stout/include/stout/os/windows/close.hpp ff635e44235d63888a210cd68d49f6678a851e31 3rdparty/stout/include/stout/os/windows/dup.hpp 265046cf7ffc14f7326711d295aa7dd4f0a8a1e3 3rdparty/stout/include/stout/os/windows/fcntl.hpp bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 3rdparty/stout/include/stout/os/windows/fd.hpp d7f8cdf1ad877eb55589bf5a9e75d295f91990a7 3rdparty/stout/include/stout/os/windows/pipe.hpp 365db9480f6258a03ef2e760a19abef8ab177e58 3rdparty/stout/include/stout/os/windows/read.hpp 8047ad590fcc46d3ec46b551472d8c518ae49cc1 3rdparty/stout/include/stout/os/windows/socket.hpp 259b05b8c85e399feaccec698d58b7d540cad368 3rdparty/stout/include/stout/os/windows/write.hpp 71006489918d9495d37d2fdfdca08b40b419481a 3rdparty/stout/tests/os/filesystem_tests.cpp c190baa2230298e428d4034b90dccffb59b4e710 3rdparty/stout/tests/os/socket_tests.cpp 8ea0f1238e4293a5cd313b4ee38a920b381f4022 Diff: https://reviews.apache.org/r/66437/diff/6/ Changes: https://reviews.apache.org/r/66437/diff/5-6/ Testing ------- Thanks, Andrew Schwartzmeyer