Defining an event loop abstraction

[Lennart Poettering]

Hi!

There have been several attempts to establish a common event loop
library as a "standard" for Linux/Unix applications in the recent
past. (To name a few: liboop, libevent, the "Common main loop" as
discussed on the XDG mailing list). None of them gained support from
more than a handful of applications, and more importantly, none of
them got support by any of the major desktop environments/GUI
libraries.

The reasoning behind all those attempts is primarily to ease the
integration of external libraries into application event loops. I
believe this is a worthy goal, but I doubt that implementing yet
another main loop library will sufficiently solve it and have
success. It is impossible to design a main loop that makes everyone
happy. 

Therefore I'd like to suggest a different solution: not defining a new
library, but just defining a new API, specifically a header file. That
API only provides the bare minmum which is needed to abstract an event
loop. How could this look like? In Avahi we defined such an
abstraction in this header file:

http://www.freedesktop.org/~lennart/doxygen/watch_8h-source.html

As you can see, we do not define a single function prototype. Instead
we define a structure which is kind of a vmt for just seven
methods. Only two sources of events are known, file descriptors and
timeouts. (no unix signals, they shouldn't be used by libraries
anyway, and can be implemented on top of fd events in the application,
if required)

This abstraction is powerful enough to drive both avahi's core (which
is quite complicated, since it uses lots of time events, and UNIX
signals and everything) and avahi-client which is a wrapper around the
DBUS libraries.

Many libraries already contain a main loop abstraction of some
kind. (e.g. DBUS, Avahi, ALSA, ...) The idea is to make them use this
abstraction instead. Main loop implementors like glib, qt or libevent should
implement one of these AvahiPoll objects. Consumer libraries, such as
libavahi-client, libxmlrpc and suchlike should take one of these
objects. 

With avahi we ship AvahiPoll implementations for Qt3, Qt4, Glib and a
native implementation based on poll(). For qt3 and qt4 we offer a
single function which returns a pointer to a static AvahiPoll
object. For glib we implement AvahiPoll as a GSource object. You can
allocate more than one of them and make use of the glib event priority
system that way - no functionality is lost due to the abstraction.

The abstraction should be powerful enough to port both the qt and the
glib main loop to it. However, there's not proof of concept for that.

I wonder if it makes sense to define such a header file under the
umbrella of fd.o. Every library that either implements a vtable or
makes use of it should ship it as part of their installed header
files. I want to stress that with this solution there will be no
central library package that implements adapters for all kinds of main
loops. Instead the header file is everything that is made available
via fd.o. In a way this is similar to the header file defined by the
LADSPA people.

What do you think?

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] de
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/