[
https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144145#comment-14144145
]
Joris Van Remoortere commented on MESOS-1330:
---------------------------------------------
I have been working with Nik on this, and have a basic prototype for
disentangling libev from process (process.cpp).
I am trying to keep semantic changing modifications separate from refactoring,
so the following changes as little as possible:
https://github.com/mesosphere/mesos/tree/abstract-event-manager
The key take-aways are:
1) There is now an interface called EventManager. It is a combination of the
old SocketManager, with a couple of extra functions for dealing with timer
injections into event loops. It also has pure virtuals for the io::* (such as
poll, read, write) so those can be implemented behind the abstraction as well.
2) Libev is hidden inside libev_event_manager.cpp. It is an implementation of
the EventManager abstraction. It uses PIMPL pattern to hide all of Libev (ev.h)
in a single cpp so that the function declarations are not exposed elsewhere
accidentally.
3) Some dependency injection was used (e.g. EventManager::ProcessManager, and
internal::EventManager) in order to dis-entangle EventManager from
ProcessManager, and HttpProxy from EventManager.
4) #3 allowed us to factor HttpProxy out of process.cpp and into it's own
hpp/cpp file, as part of trimming process.cpp. The current EventManager
interface also exposes HttpProxy (as we did not want to change the semantics of
SocketManager yet), so it needed to be visible in the interface definition.
I would like to be able to turn this abstraction into a plugable module (using
the newly proposed module API), but that is a further step. For now I've just
moved the libev implementation out and deal with it in the abstract sense in
process.cpp.
If the subject of virtual dispatch performance comes up, as long as we're
building with flto, and the compiler is able to statically determine that only
1 EventManager implementation is used, it will be able to de-virtualize the
whole thing and get the same performance as the previous version. Even if we
made this a module, if it were statically linked in and then re-optimized this
would also work.
Looking forward to your thoughts.
> Introduce connection/transport abstraction to stout
> ---------------------------------------------------
>
> Key: MESOS-1330
> URL: https://issues.apache.org/jira/browse/MESOS-1330
> Project: Mesos
> Issue Type: Improvement
> Components: general, libprocess
> Reporter: Niklas Quarfot Nielsen
> Labels: libprocess, network
>
> I think it makes sense to think in terms of different low or middle layer
> transports (which can accommodate channels like SSL). We could capture
> connection life-cycles and network send/receive primitives in a much explicit
> manner than currently in libprocess.
> I have a proof of concept transport / connection abstraction ready and which
> we can use to iterate a design.
> Notably, there are opportunities to change the current SocketManager/Socket
> abstractions to explicit ConnectionManager/Connection, which allow several
> and composeable communication layers.
> I am proposing to own this ticket and am looking for a shepherd to
> (thoroughly) go over design considerations before jumping into an actual
> implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
