mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Clemmer <clemmer.alexan...@gmail.com>
Subject Re: Review Request 54591: Introduced `WindowsFD` class which is analogous to an `int` in POSIX.
Date Sun, 05 Feb 2017 08:48:57 GMT

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




3rdparty/stout/include/stout/os/windows/fd.hpp (line 20)
<https://reviews.apache.org/r/54591/#comment235939>

    Should these be alphabetized?



3rdparty/stout/include/stout/os/windows/fd.hpp (line 59)
<https://reviews.apache.org/r/54591/#comment235941>

    I'm not super up on the semantics of these newfangled C++11 constructor things, but is
there any particular reason we need this to be trivially constructible, or anything like that?
Because, if there's not any significant gain, I think it's worth wondering whether having
a default value is slightly dangerous.



3rdparty/stout/include/stout/os/windows/fd.hpp (line 71)
<https://reviews.apache.org/r/54591/#comment235940>

    Is it true that we're expecting `HANDLE`s passed to this class to only correspond to files?
    
    If not, I think it's worth noting that `INVALID_HANDLE_VALUE` is not the error value of
all `HANDLE`s returned from the win32 APIs, _cf_. the "documentation" at [1]. Depending on
the "type" of `HANDLE` returned, an error could be denoted by the handle being `== NULL`,
`== -1`, and even `<= 32` in the case of `ShellExecute`. See [2].
    
    If yes, I think it's worth at least documenting this as part of the class. (Honestly,
I would prefer file `HANDLE`s be a different type entirely, but here we are.)
    
    [1] https://blogs.msdn.microsoft.com/oldnewthing/20040302-00/?p=40443
    [2] http://stackoverflow.com/questions/3905538/testing-for-an-invalid-windows-handle-should-i-compare-with-null-0-or-even



3rdparty/stout/include/stout/os/windows/fd.hpp (line 86)
<https://reviews.apache.org/r/54591/#comment235942>

    In `crt`, why not check the `type_` here and `abort` if the type is not compatible with
what is requested, sort of like how we do in `Try`? It seems like it's better to replace a
subtle error with an obvious one.
    
    I'm not sure if this also makes sense for the `operator`s below, too?



3rdparty/stout/include/stout/os/windows/fd.hpp (line 306)
<https://reviews.apache.org/r/54591/#comment235944>

    I'm a bit confused about the conversion logic here... if `left` is a CRT type, can't we
just `static_cast<HANDLE>(left)` and compare that to the right? What am I missing?
    
    Also just so I'm clear: your comment above is saying that the check of `< 0` is just
because `left` is signed, while `right` is unsigned, so they can't be equal in this case?
Is it appropriate to do a `static_assert` to make sure `HANDLE` is unsigned in the future,
too?



3rdparty/stout/include/stout/os/windows/fd.hpp (line 311)
<https://reviews.apache.org/r/54591/#comment235943>

    Just for my own education, we are doing a `reinterpret_cast` here? Can we not just `static_cast<HANDLE>`?


- Alex Clemmer


On Feb. 5, 2017, 1:36 a.m., Michael Park wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54591/
> -----------------------------------------------------------
> 
> (Updated Feb. 5, 2017, 1:36 a.m.)
> 
> 
> Review request for mesos, Daniel Pravat and Joris Van Remoortere.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> In POSIX the socket, pipe and a file are represented by the `int` type.
> In Windows:
>   - A socket is kept in a `SOCKET` type (64 bit wide)
>   - A pipe or a WinAPI file descriptor in a `HANDLE` (64 bit wide)
>   - A CRT file descriptor in an `int`
> 
> The `WindowsFD` class is a type that brings all of these things
> together and behaves analogously to an `int` in POSIX.
> 
> 
> Diffs
> -----
> 
>   3rdparty/stout/include/stout/os.hpp ed6fec3ac1c1f9dfb0585178401f4b552822a0a1 
>   3rdparty/stout/include/stout/os/int_fd.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/windows/fd.hpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/54591/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Michael Park
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message