1.3. History

We have need for system events/file handles monitoring for uLan project and other PiKRON company projects in 2007. The selected solution should provide functionality of other older Sys V poll based code included in OCERA project CAN/CANopen VCA component as well.

The libevent looked as good candidate for our projects at that time, even that it would add yet another prerequisite for our projects. It was considered acceptable. But the goal of our libraries/components was to allow their combination in environment based on other main-loop implementation (Qt, GTK, Python). But libevent enforces its own main loop and prevents to use libraries based on it to integrate into other environment main loop mechanism. This was considered as fundamental problem and the goals (Section 1.1) for required solution has been defined.

The minimal API conforming these requirements and allowing separation of libraries code from used system event processing method has been defined.

Then the simple Sys V poll based implementation has been provided to allow stand-alone use of the API without enforcing external dependencies. The use of libevent-1 has been considered as next target. But after deeper look at libevent-1 code distributed with Debian stable, the analysis shown, that it is unusable for multi-threaded environment - event_base_new() has not been provided by that version and sequence for creation and attaching of events to non default base has been considered strange as well.

For above reasons, the own epoll based mechanism was implemented for uLevPoll. During its testing some misbehavior in epoll Linux kernel implementation has been found. Davide Libenzi has kindly provided help and result is enhancement in Linux epoll implementation and introduction of keyed wake-ups which lead to significant speedup even for plain blocking read and write socket operations.

Next experiment was to try, if designed ABI really allows components to be compatible with Gtk/Glib and Qt. Fortunately, usual distributions Qt builds use Glib main loop so only support for that was added to uLevPoll. It allows to hide Glib event sources based API under uLevPoll API for our libraries which can then transparently use Glib main loop without notice of that. Yet for different threads better performing epoll base main loop can be used. Even for main thread event loop it is possible to cascade over uLevPoll Glib abstraction another uLevPoll base with different mechanism (epoll for example) which is great win because Glib main loop has horrible scalability.

Then the time to finally try move to libevent come. But version 1 has been disappointing. But new development version 2 shows in much better light. It really allows multi-threaded support and when more available by distributions, it would allow to use it as high performance mechanism for uLevPoll. uLevPoll wrapper code has been adapted for libevent 2 now.