Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search


Related bug link:

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


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

Does not support Windows.

BSD or GPL v2 or later.


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

BSD license.


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

MIT license.


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.


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