On Wed, 13.11.13 17:18, Colin Walters ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
