Skip to main content
Jump to: navigation, search

Mosquitto/EventLoop

Related bug link: https://bugs.eclipse.org/bugs/show_bug.cgi?id=470008

Moving to using an event loop library has a number of advantages over the current poll() implementation.

  • Improved performance compared to poll() - e.g. epoll() on Linux.
  • Not limited to 1024 connections on Windows.
  • Improved websockets performance (through proper integration, this could also be achieved on the current poll() interface with some effort)

Possible libraries

libev

Supports epoll, kqueue, event ports, inotify, eventfd, signalfd.

Does not support Windows.

BSD or GPL v2 or later.

libevent

Supports /dev/poll, kqueue, POSIX select, Windows select, poll, epoll and Solaris event ports.

BSD license.

libuv

Supports epoll, kqueue, Windows IOCP, and Solaris event ports.

MIT license.

Discussion

Portability, development status

An important consideration is portability. This puts libuv as the clear choice because of its IOCP support on Windows. libuv is under active development. libevent claims IOCP support for their version 2.1, but this has been in alpha for a very long time. libev does not appear to be actively developed.

libuv does not currently provide Windows binaries, but work is under way to change this.

Websockets

libwebsockets, the optional dependency that mosquitto uses to provide websockets support has support for libev but no other event library. It is important that libwebsockets can be made to work with the final event library.

IP concerns

No event library requires a CLA to contribute which is problematic. By its nature, using an event library will be a core decision for the mosquitto code and so could not be an optional dependency. This means that the best option will be to attempt to use the library as an exempt prerequisite - i.e. the library must be widely available.

Back to the top