mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Schwartzmeyer <>
Subject Re: Review Request 66438: Windows: Made `libevent` use `int_fd` correctly.
Date Fri, 27 Apr 2018 20:50:51 GMT

This is an automatically generated e-mail. To reply, visit:

(Updated April 27, 2018, 1:50 p.m.)

Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, and Michael Park.


This fixes the SSL build.

Summary (updated)

Windows: Made `libevent` use `int_fd` correctly.

Bugs: MESOS-8675

Repository: mesos

Description (updated)

Due to the refactoring of `int_fd`, we have two corrections to make.

The first is an edge case where `libevent`, a third-party library,
requires a CRT integer file descriptor. Thus we duplicate the `int_fd`
and then explicitly allocate via `crt()`, which requires that we also
manually close it via `_close()`.

The second is an edge case where `libevent` uses its own type to
represent a `SOCKET` on Windows, in this case,
`evutil_socket_t` (which is actually just an `intptr_t`). While
`int_fd` has a constructor for this type, it is marked `explicit`, and
unfortunately also has an implicit constructor which takes an `int`.
This is a problem because the `intptr_t` can be silently converted to
an `int`, causing the `int_fd` abstraction to take on the wrong
form (a `HANDLE` instead of a `SOCKET`). So to avoid this implicit
conversion, we call the `intptr_t` constructor explicitly.

The alternative is to make the `intptr_t` constructor implicit, which
we wish to avoid, or to make the `int` constructor explicit, which we
can't do because we need to support `int` semantics such as
`int_fd fd = -1`.

Diffs (updated)

  3rdparty/libprocess/src/libevent_ssl_socket.cpp 4de161dbf9198e9c74b1e80838b8a5d52006a562





Andrew Schwartzmeyer

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