mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Schwartzmeyer <and...@schwartzmeyer.com>
Subject Re: Review Request 67385: Windows: Added IOCP `HANDLE` to `WindowsFD`.
Date Tue, 05 Jun 2018 21:02:16 GMT

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




3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 181 (patched)
<https://reviews.apache.org/r/67385/#comment286813>

    Maybe just `HANDLE handle` ;)



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 181-182 (patched)
<https://reviews.apache.org/r/67385/#comment286819>

    What is the `key` used for? (Maybe we need a small excerpt from the MSDN docs for `CreateIoCompletionPort`.)



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 183 (patched)
<https://reviews.apache.org/r/67385/#comment286812>

    I'm not saying you should use it, or if you even want to use it, but there does exist
some synchronization helpers in stout, under `synchronized.hpp`.



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 183-184 (patched)
<https://reviews.apache.org/r/67385/#comment286817>

    Is there ever a case where `iocp_handle_` hasn't been allocated? Right now, this is implicitly
relying on the fact that we chose to make the default constructor construct off the `HANDLE`
ctor with `INVALID_HANDLE_VALUE`, and that ctor uses `make_shared`. Just wondering if we should
refactor to make the allocation more explicit and certain (like maybe to `make_shared` in
the default ctor, and ensure all ctors call it too, I don't know yet).



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 184 (patched)
<https://reviews.apache.org/r/67385/#comment286820>

    `const`



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 188 (patched)
<https://reviews.apache.org/r/67385/#comment286818>

    Oi, I hate that our cast operators are implicit, `*this` threw me for a minute.



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 202-215 (patched)
<https://reviews.apache.org/r/67385/#comment286809>

    Old comment, but leaving for posterity:
    
    I don't like this `WindowsFD::dup` method; it opens up a can of worms, such as: should
we move the `os::dup` logic into this method (should we then start moving other `os::foo(int_fd)`
logic into their own methods)? It also prompted me to think about this maybe being done in
a copy ctor, but that doesn't make sense either.
    
    At a minimum, let's make this `private` and make `os::dup` a `friend` so that `WindowsFD::dup`
is clearly demarcated as an internal helper.
    
    And once I wrote that, I almost want to suggest: make `os::dup` a friend, and just make
a new `fd` and manually assign the `overlapped_` and `iocp_handle_` fields (that is, get rid
of the helper abstraction). Not sure if that would be cleaner.



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 231-235 (patched)
<https://reviews.apache.org/r/67385/#comment286815>

    This is more like `struct IOCPData`, since it's both the handle and the mutex.



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 237 (patched)
<https://reviews.apache.org/r/67385/#comment286814>

    This could just be named `iocp_`



3rdparty/stout/include/stout/os/windows/fd.hpp
Lines 239-257 (patched)
<https://reviews.apache.org/r/67385/#comment286811>

    As discussed in-person, we can simplify all this logic (read: delete these ctors and the
`dup` method) by making `os::dup` a friend, using the default copy ctor in `os::dup`, and
then overwriting the `handle_` or `socket_` field with the duplicated object (which is then
doable as a friend function).


- Andrew Schwartzmeyer


On May 30, 2018, 11:58 a.m., Akash Gupta wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67385/
> -----------------------------------------------------------
> 
> (Updated May 30, 2018, 11:58 a.m.)
> 
> 
> Review request for mesos, Andrew Schwartzmeyer, Benjamin Mahler, Eric Mumau, John Kordich,
Joseph Wu, and Radhika Jandhyala.
> 
> 
> Bugs: MESOS-5371 and MESOS-8668
>     https://issues.apache.org/jira/browse/MESOS-5371
>     https://issues.apache.org/jira/browse/MESOS-8668
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Mesos/Libprocess uses `os::nonblock()` in a way that assumes that it is
> idempotent. Unfortunately, `CreateIoCompletionPort` is not idempotent,
> so we need to wrap the function around our own code to make it so. We
> need to keep it inside the `WindowsFD` class, because there isn't a way
> to determine if a HANDLE is associated with an IOCP through the Win32
> API.
> 
> 
> Diffs
> -----
> 
>   3rdparty/stout/include/stout/os/windows/dup.hpp 5bda095e676b038cdaea04f7be23ba2a1aca9015

>   3rdparty/stout/include/stout/os/windows/fd.hpp 5dbdff2680370d123579c5e3fdd9b0e0adaf512e

> 
> 
> Diff: https://reviews.apache.org/r/67385/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Akash Gupta
> 
>


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