-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66437/
-----------------------------------------------------------

(Updated April 6, 2018, 4:15 p.m.)


Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, and 
Michael Park.


Changes
-------

Implemented default ctor to explicitly initialize as an invalid handle.


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.


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/read.hpp 
8047ad590fcc46d3ec46b551472d8c518ae49cc1 
  3rdparty/stout/include/stout/os/windows/write.hpp 
71006489918d9495d37d2fdfdca08b40b419481a 
  3rdparty/stout/tests/os/filesystem_tests.cpp 
c190baa2230298e428d4034b90dccffb59b4e710 


Diff: https://reviews.apache.org/r/66437/diff/3/

Changes: https://reviews.apache.org/r/66437/diff/2-3/


Testing
-------


Thanks,

Andrew Schwartzmeyer

Reply via email to