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 2017/09/22 18:34:14 UTC
Review Request 62510: Fixed `LibeventSSLSocketImpl` for Windows file
descriptors.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62510/
-----------------------------------------------------------
Review request for mesos, John Kordich, Joseph Wu, and Till Toenshoff.
Bugs: MESOS-7992
https://issues.apache.org/jira/browse/MESOS-7992
Repository: mesos
Description
-------
This patch introduces the `int_fd` abstraction we use elsewhere to the
`LibeventSSLSocketImpl` for dealing with Linux versus Windows file
descriptors. This is necessary because on Windows, the consumer of
`LibeventSSLSocketImpl::create()` etc. already use `int_fd`.
Note that this does not break Linux systems, as `int_fd` is defined as
`int` on all non-Windows systems.
On Windows, however, in `evbuffer_add_file` we must explicitly convert
from `int_fd` (holding a Windows file handle) to a CRT `int` file
descriptor (the platform-specific call to `crt()`).
We have to correct the type expected by `evconnlistener_new` from `int`
to `evutil_socket_t`. This previously worked as just an `int` because
that is the underlying type used for sockets by libevent on Linux, but
it instead uses `intptr_t` on Windows. The `int_fd` abstraction can be
casted to `intptr_t` (and thus `evutil_socket_t`) automatically, but not
`int`, and so correcting the type to `evutil_socket_t` allows us to use
this lambda for the listener.
Diffs
-----
3rdparty/libprocess/src/libevent_ssl_socket.hpp 9493a50243340a1c48ab1c67f6e61cc081ef24ce
3rdparty/libprocess/src/libevent_ssl_socket.cpp 5767ce04391ee37076d9f97f65084febd0aefbdb
Diff: https://reviews.apache.org/r/62510/diff/1/
Testing
-------
Thanks,
Andrew Schwartzmeyer
Re: Review Request 62510: Fixed `LibeventSSLSocketImpl` for Windows
file descriptors.
Posted by Joseph Wu <jo...@mesosphere.io>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62510/#review186881
-----------------------------------------------------------
Ship it!
LGTM.
- Joseph Wu
On Sept. 22, 2017, 11:34 a.m., Andrew Schwartzmeyer wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62510/
> -----------------------------------------------------------
>
> (Updated Sept. 22, 2017, 11:34 a.m.)
>
>
> Review request for mesos, John Kordich, Joseph Wu, and Till Toenshoff.
>
>
> Bugs: MESOS-7992
> https://issues.apache.org/jira/browse/MESOS-7992
>
>
> Repository: mesos
>
>
> Description
> -------
>
> This patch introduces the `int_fd` abstraction we use elsewhere to the
> `LibeventSSLSocketImpl` for dealing with Linux versus Windows file
> descriptors. This is necessary because on Windows, the consumer of
> `LibeventSSLSocketImpl::create()` etc. already use `int_fd`.
>
> Note that this does not break Linux systems, as `int_fd` is defined as
> `int` on all non-Windows systems.
>
> On Windows, however, in `evbuffer_add_file` we must explicitly convert
> from `int_fd` (holding a Windows file handle) to a CRT `int` file
> descriptor (the platform-specific call to `crt()`).
>
> We have to correct the type expected by `evconnlistener_new` from `int`
> to `evutil_socket_t`. This previously worked as just an `int` because
> that is the underlying type used for sockets by libevent on Linux, but
> it instead uses `intptr_t` on Windows. The `int_fd` abstraction can be
> casted to `intptr_t` (and thus `evutil_socket_t`) automatically, but not
> `int`, and so correcting the type to `evutil_socket_t` allows us to use
> this lambda for the listener.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/src/libevent_ssl_socket.hpp 9493a50243340a1c48ab1c67f6e61cc081ef24ce
> 3rdparty/libprocess/src/libevent_ssl_socket.cpp 5767ce04391ee37076d9f97f65084febd0aefbdb
>
>
> Diff: https://reviews.apache.org/r/62510/diff/1/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Andrew Schwartzmeyer
>
>
Re: Review Request 62510: Fixed `LibeventSSLSocketImpl` for Windows
file descriptors.
Posted by Joseph Wu <jo...@mesosphere.io>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62510/#review187706
-----------------------------------------------------------
Ship it!
Ship It!
- Joseph Wu
On Oct. 2, 2017, 4:47 p.m., Andrew Schwartzmeyer wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62510/
> -----------------------------------------------------------
>
> (Updated Oct. 2, 2017, 4:47 p.m.)
>
>
> Review request for mesos, John Kordich, Joseph Wu, and Till Toenshoff.
>
>
> Bugs: MESOS-7992
> https://issues.apache.org/jira/browse/MESOS-7992
>
>
> Repository: mesos
>
>
> Description
> -------
>
> This patch introduces the `int_fd` abstraction we use elsewhere to the
> `LibeventSSLSocketImpl` for dealing with Linux versus Windows file
> descriptors. This is necessary because on Windows, the consumer of
> `LibeventSSLSocketImpl::create()` etc. already use `int_fd`.
>
> Note that this does not break Linux systems, as `int_fd` is defined as
> `int` on all non-Windows systems.
>
> On Windows, however, in `evbuffer_add_file` we must explicitly convert
> from `int_fd` (holding a Windows file handle) to a CRT `int` file
> descriptor (the platform-specific call to `crt()`).
>
> We have to correct the type expected by `evconnlistener_new` from `int`
> to `evutil_socket_t`. This previously worked as just an `int` because
> that is the underlying type used for sockets by libevent on Linux, but
> it instead uses `intptr_t` on Windows. The `int_fd` abstraction can be
> casted to `intptr_t` (and thus `evutil_socket_t`) automatically, but not
> `int`, and so correcting the type to `evutil_socket_t` allows us to use
> this lambda for the listener.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/src/libevent_ssl_socket.hpp 9493a50243340a1c48ab1c67f6e61cc081ef24ce
> 3rdparty/libprocess/src/libevent_ssl_socket.cpp 5767ce04391ee37076d9f97f65084febd0aefbdb
>
>
> Diff: https://reviews.apache.org/r/62510/diff/1/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Andrew Schwartzmeyer
>
>
Re: Review Request 62510: Fixed `LibeventSSLSocketImpl` for Windows
file descriptors.
Posted by Andrew Schwartzmeyer <an...@schwartzmeyer.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62510/
-----------------------------------------------------------
(Updated Oct. 2, 2017, 4:47 p.m.)
Review request for mesos, John Kordich, Joseph Wu, and Till Toenshoff.
Changes
-------
Inserted patch into middle of chain, fixed dependency.
Bugs: MESOS-7992
https://issues.apache.org/jira/browse/MESOS-7992
Repository: mesos
Description
-------
This patch introduces the `int_fd` abstraction we use elsewhere to the
`LibeventSSLSocketImpl` for dealing with Linux versus Windows file
descriptors. This is necessary because on Windows, the consumer of
`LibeventSSLSocketImpl::create()` etc. already use `int_fd`.
Note that this does not break Linux systems, as `int_fd` is defined as
`int` on all non-Windows systems.
On Windows, however, in `evbuffer_add_file` we must explicitly convert
from `int_fd` (holding a Windows file handle) to a CRT `int` file
descriptor (the platform-specific call to `crt()`).
We have to correct the type expected by `evconnlistener_new` from `int`
to `evutil_socket_t`. This previously worked as just an `int` because
that is the underlying type used for sockets by libevent on Linux, but
it instead uses `intptr_t` on Windows. The `int_fd` abstraction can be
casted to `intptr_t` (and thus `evutil_socket_t`) automatically, but not
`int`, and so correcting the type to `evutil_socket_t` allows us to use
this lambda for the listener.
Diffs
-----
3rdparty/libprocess/src/libevent_ssl_socket.hpp 9493a50243340a1c48ab1c67f6e61cc081ef24ce
3rdparty/libprocess/src/libevent_ssl_socket.cpp 5767ce04391ee37076d9f97f65084febd0aefbdb
Diff: https://reviews.apache.org/r/62510/diff/1/
Testing
-------
Thanks,
Andrew Schwartzmeyer