[systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation

[Lennart Poettering]

On Wed, 13.11.13 17:18, Colin Walters (walters at verbum.org) wrote:

> 
> On Thu, 2013-11-14 at 06:49 +0900, Marcel Holtmann wrote:
> 
> > that is the long term plan. Once ConnMan is switching over to use libsystemd-bus and kdbus,
> > we are switching over to using the systemd event loop instead of GLib main loop 
> 
> But I think the long term architecturally correct place for the core
> system main loop is glibc, not systemd.
> 
> For example, that would allow runtimes like OpenJDK and Python to
> unconditionally depend on it (if present).
> 
> As systemd's event loop becomes public API, it has the potential to
> create interoperability problems for GNOME - think applications like 
> https://git.gnome.org/browse/gnome-logs
> that want to both monitor the systemd journal and talk to GTK+.
> 
> At the moment it's OK because sd_journal has APIs sufficient to plug in
> external loops.
> 
> Adding a mainloop API to glibc would be a lot of work - it might even
> entail trying to get it by POSIX.  At least it'd entail describing the
> interaction with the other POSIX APIs.  But I think that'd be worth the
> effort.

I am pretty sure it makes sense to have domain-specific event loops. I
am not convinced that it would even be possible to unify all event loop
implementations into one. For example, GLib and and sd-event support
priorization of events, which means we need to flush all queued events
from the kernel before we decide which one to run first. This however is
probably not the best choice for a number of other usecases, where you
want to optimize for ridiculous numbers of fds. Hence, I believe
developers should get a lot of freedom on how much or how little event
loop they want, and which implementation they choose.

Then, GMainLoop can do some things sd-event cannot do. sd-event can do a
number of things GMainLoop cannot do.

I doubt moving OpenJDK or Python to sd-event or something like it ever
would make sense. (Do either even have any event loop? Java at least
prefers async stuff via threads as the solution for IO, not multiplexing
via poll()-like stuff -- which they only added very very late to the
language...).

For all event loop consuming library code I write I will make sure that
it can be connected to any reasonable event loop, not only sd-event.

I mean, libsystemd-bus already includes two event loop implementations,
one in sd-event, and another trivial one in sd_bus_wait() in a way...

So, please do not understand sd-event as an attempt to get everybody to
use the same event loop. It's just an attempt to provide a good event
loop by default, that is more useful than pure epoll (such as sanely
handles lots of timers), that tries to provide some of the features that
GMainLoop supported since a longer time (like timer coalescing or
priorisation), that we need for low-level stuff (like OOM safety, this
stuff should run in PID1...), and is generally just code that people can
use, if they want, but don't have to. Not an attempt for standardisation
but an attempt to just provide code that solves naked epoll()'s problems,
without going overboard and turning into libev/libevent.

Lennart

-- 
Lennart Poettering, Red Hat