mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <bmah...@apache.org>
Subject Re: Review Request 69082: Correctly propagated `close` failures in some instances.
Date Fri, 18 Jan 2019 17:59:06 GMT

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


Fix it, then Ship it!





3rdparty/stout/include/stout/os/posix/mktemp.hpp
Line 43 (original), 43 (patched)
<https://reviews.apache.org/r/69082/#comment297789>

    s/path/template/ and s/string/path/ would be clearer?



3rdparty/stout/include/stout/os/posix/mktemp.hpp
Line 55 (original), 54 (patched)
<https://reviews.apache.org/r/69082/#comment297788>

    This statement reads rather confusingly, I initially thought we were trying to return
the error as a string
    
    One reason is that probably s/path/template/ and s/string/path/ would be clearer
    
    But also, per the comment above, returning the error directly here would be simpler?



3rdparty/stout/include/stout/os/write.hpp
Line 143 (original), 140-146 (patched)
<https://reviews.apache.org/r/69082/#comment297787>

    ditto here



3rdparty/stout/include/stout/protobuf.hpp
Lines 163-164 (patched)
<https://reviews.apache.org/r/69082/#comment297785>

    Assigning this to `write` makes this seem a bit confusing to read, logically we're trying
to do:
    
    ```
    if write was ok but close failed:
      return close error
      
    return write
    ```
    
    so perhaps a direct return is clearer than having `write` store both write and close errors?
    
    ```
      if (write.isSome() && close.isError()) {
        return Error(...);
      }
      
      return write;
    ```



3rdparty/stout/include/stout/protobuf.hpp
Lines 164 (patched)
<https://reviews.apache.org/r/69082/#comment297784>

    Does `stringify(*fd)` make it fit on one line?



3rdparty/stout/include/stout/protobuf.hpp
Line 197 (original), 197-203 (patched)
<https://reviews.apache.org/r/69082/#comment297786>

    ditto here


- Benjamin Mahler


On Jan. 16, 2019, 1:06 p.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/69082/
> -----------------------------------------------------------
> 
> (Updated Jan. 16, 2019, 1:06 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Chun-Hung Hsiao, and Alex Clemmer.
> 
> 
> Bugs: MESOS-9331
>     https://issues.apache.org/jira/browse/MESOS-9331
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> When e.g., writing to disk, errors from write might only manifest at
> ::close time. We update some instances to correctly propagate these
> errors instead of dropping them silently. We only propagate the
> ::close error if the write operation succeeded, otherwise we just
> propagate the error from the write operation.
> 
> 
> Diffs
> -----
> 
>   3rdparty/stout/include/stout/os/posix/mktemp.hpp 63b3d1a7720d07f877fa1d4eb7f32a548916637a

>   3rdparty/stout/include/stout/os/write.hpp f7538f94f5a953a7a90a05bc1d2f138b6c17f814

>   3rdparty/stout/include/stout/protobuf.hpp eb4adef56f1701e3c101284e05e4e6c66eef9180

> 
> 
> Diff: https://reviews.apache.org/r/69082/diff/3/
> 
> 
> Testing
> -------
> 
> `make check`
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>


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