You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Andrew Schwartzmeyer <an...@schwartzmeyer.com> on 2018/02/01 23:23:50 UTC
Re: Review Request 65403: Windows: Disabled `O_CLOEXEC` semantic
mapping on Windows.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65403/
-----------------------------------------------------------
(Updated Feb. 1, 2018, 3:23 p.m.)
Review request for mesos, Akash Gupta, Jie Yu, and Joseph Wu.
Summary (updated)
-----------------
Windows: Disabled `O_CLOEXEC` semantic mapping on Windows.
Bugs: MESOS-5882
https://issues.apache.org/jira/browse/MESOS-5882
Repository: mesos
Description (updated)
-------
Previously we mapped `O_CLOEXEC` to `O_NOINHERIT`, which is close to the
intended semantics, but not close enough. Instead, we want all Windows
handles by default to be non-inheritable, and not tie any Windows
inheritance semantics to the close-on-exec semantics. So, we define
`O_CLOEXEC` on Windows to be `0`, and remove the logging from the
`os::cloexec` family of functions because do not ever intend to
implement them.
We achieve the "close" part of the semantics by making all handles
non-inheritable, as the intent is to avoid leaking handles.
Diffs (updated)
-----
3rdparty/stout/include/stout/os/open.hpp 6711f22d44b0e7c13da3abd51f9fb7b71779e868
3rdparty/stout/include/stout/os/windows/fcntl.hpp 5800ec92f85401a80cb813afd880be2e5a24a3af
Diff: https://reviews.apache.org/r/65403/diff/2/
Changes: https://reviews.apache.org/r/65403/diff/1-2/
Testing
-------
Thanks,
Andrew Schwartzmeyer
Re: Review Request 65403: Windows: Disabled `O_CLOEXEC` semantic
mapping on Windows.
Posted by Jeff Coffler <je...@taltos.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65403/#review197795
-----------------------------------------------------------
Ship it!
Ship It!
- Jeff Coffler
On Feb. 8, 2018, 10:36 p.m., Andrew Schwartzmeyer wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65403/
> -----------------------------------------------------------
>
> (Updated Feb. 8, 2018, 10:36 p.m.)
>
>
> Review request for mesos, Akash Gupta, Jie Yu, and Joseph Wu.
>
>
> Bugs: MESOS-5882
> https://issues.apache.org/jira/browse/MESOS-5882
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Previously we mapped `O_CLOEXEC` to `O_NOINHERIT`, which is close to the
> intended semantics, but not close enough. Instead, we want all Windows
> handles by default to be non-inheritable, and not tie any Windows
> inheritance semantics to the close-on-exec semantics. So, we define
> `O_CLOEXEC` on Windows to be `0`, and remove the logging from the
> `os::cloexec` family of functions because do not ever intend to
> implement them.
>
> We achieve the "close" part of the semantics by making all handles
> non-inheritable, as the intent is to avoid leaking handles.
>
>
> Diffs
> -----
>
> 3rdparty/stout/include/stout/os/open.hpp 6711f22d44b0e7c13da3abd51f9fb7b71779e868
> 3rdparty/stout/include/stout/os/windows/fcntl.hpp 5800ec92f85401a80cb813afd880be2e5a24a3af
>
>
> Diff: https://reviews.apache.org/r/65403/diff/2/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Andrew Schwartzmeyer
>
>
Re: Review Request 65403: Windows: Disabled `O_CLOEXEC` semantic
mapping on Windows.
Posted by Andrew Schwartzmeyer <an...@schwartzmeyer.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65403/
-----------------------------------------------------------
(Updated Feb. 8, 2018, 2:36 p.m.)
Review request for mesos, Akash Gupta, Jie Yu, and Joseph Wu.
Changes
-------
Re-arrange commits.
Bugs: MESOS-5882
https://issues.apache.org/jira/browse/MESOS-5882
Repository: mesos
Description
-------
Previously we mapped `O_CLOEXEC` to `O_NOINHERIT`, which is close to the
intended semantics, but not close enough. Instead, we want all Windows
handles by default to be non-inheritable, and not tie any Windows
inheritance semantics to the close-on-exec semantics. So, we define
`O_CLOEXEC` on Windows to be `0`, and remove the logging from the
`os::cloexec` family of functions because do not ever intend to
implement them.
We achieve the "close" part of the semantics by making all handles
non-inheritable, as the intent is to avoid leaking handles.
Diffs
-----
3rdparty/stout/include/stout/os/open.hpp 6711f22d44b0e7c13da3abd51f9fb7b71779e868
3rdparty/stout/include/stout/os/windows/fcntl.hpp 5800ec92f85401a80cb813afd880be2e5a24a3af
Diff: https://reviews.apache.org/r/65403/diff/2/
Testing
-------
Thanks,
Andrew Schwartzmeyer
Re: Review Request 65403: Windows: Disabled `O_CLOEXEC` semantic
mapping on Windows.
Posted by Joseph Wu <jo...@mesosphere.io>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65403/#review196759
-----------------------------------------------------------
Ship it!
- Joseph Wu
On Feb. 1, 2018, 3:23 p.m., Andrew Schwartzmeyer wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65403/
> -----------------------------------------------------------
>
> (Updated Feb. 1, 2018, 3:23 p.m.)
>
>
> Review request for mesos, Akash Gupta, Jie Yu, and Joseph Wu.
>
>
> Bugs: MESOS-5882
> https://issues.apache.org/jira/browse/MESOS-5882
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Previously we mapped `O_CLOEXEC` to `O_NOINHERIT`, which is close to the
> intended semantics, but not close enough. Instead, we want all Windows
> handles by default to be non-inheritable, and not tie any Windows
> inheritance semantics to the close-on-exec semantics. So, we define
> `O_CLOEXEC` on Windows to be `0`, and remove the logging from the
> `os::cloexec` family of functions because do not ever intend to
> implement them.
>
> We achieve the "close" part of the semantics by making all handles
> non-inheritable, as the intent is to avoid leaking handles.
>
>
> Diffs
> -----
>
> 3rdparty/stout/include/stout/os/open.hpp 6711f22d44b0e7c13da3abd51f9fb7b71779e868
> 3rdparty/stout/include/stout/os/windows/fcntl.hpp 5800ec92f85401a80cb813afd880be2e5a24a3af
>
>
> Diff: https://reviews.apache.org/r/65403/diff/2/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Andrew Schwartzmeyer
>
>
Re: Review Request 65403: Windows: Disabled `O_CLOEXEC` semantic
mapping on Windows.
Posted by Akash Gupta <ak...@hotmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65403/#review197032
-----------------------------------------------------------
Ship it!
Ship It!
- Akash Gupta
On Feb. 1, 2018, 11:23 p.m., Andrew Schwartzmeyer wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65403/
> -----------------------------------------------------------
>
> (Updated Feb. 1, 2018, 11:23 p.m.)
>
>
> Review request for mesos, Akash Gupta, Jie Yu, and Joseph Wu.
>
>
> Bugs: MESOS-5882
> https://issues.apache.org/jira/browse/MESOS-5882
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Previously we mapped `O_CLOEXEC` to `O_NOINHERIT`, which is close to the
> intended semantics, but not close enough. Instead, we want all Windows
> handles by default to be non-inheritable, and not tie any Windows
> inheritance semantics to the close-on-exec semantics. So, we define
> `O_CLOEXEC` on Windows to be `0`, and remove the logging from the
> `os::cloexec` family of functions because do not ever intend to
> implement them.
>
> We achieve the "close" part of the semantics by making all handles
> non-inheritable, as the intent is to avoid leaking handles.
>
>
> Diffs
> -----
>
> 3rdparty/stout/include/stout/os/open.hpp 6711f22d44b0e7c13da3abd51f9fb7b71779e868
> 3rdparty/stout/include/stout/os/windows/fcntl.hpp 5800ec92f85401a80cb813afd880be2e5a24a3af
>
>
> Diff: https://reviews.apache.org/r/65403/diff/2/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Andrew Schwartzmeyer
>
>