Login
Newsletter
Werbung

Mo, 23. November 2015, 13:25

Software::Systemverwaltung

Systemd-Projekt veröffentlicht Event-Verarbeitungsschleife

Das Systemd-Projekt hat seine selbst entwickelte Event-Verarbeitungsschleife zum stabilen Teil von libsystemd erklärt. »sd-event« steht damit auch anderen Projekten zur Verfügung. Projektinitiator Lennart Poettering diskutiert die Entstehungsgeschichte sowie Vor- und Nachteile von sd-event.

Mirko Lindner

Systemd benötigte, wie fast alle Daemonen, von Anfang an eine Ereignisbehandlung. Diese wurde ursprünglich mit Hilfe des Systemaufrufs epoll implementiert, nahm aber schnell an Komplexität zu. Zudem sah sich das Projekt in der Situation, dass derselbe oder ähnlicher Code in jedem zu Systemd gehörenden Daemon wieder zum Einsatz kam. Der Code wurde folglich vereinheitlicht und in libsystemd verschoben.

Ziel der Implementation war es, die verschiedenen Event-Quellen einheitlich zu behandeln und insbesondere, Ereignisse zu priorisieren. Dies wäre mit dem epoll-Aufruf allein nicht mehr zu machen gewesen, da dieser einige Limitierungen aufweist. Zwar verwendet sd-event weiterhin epoll, berücksichtigt aber auch andere Ereignisquellen. Ereignisse können aus Ein-/Ausgabeoperationen, Timer-Alarmen, Signalen, Zustandsänderungen von Kindprozessen und anderen Quellen stammen.

Bevor das Projekt seine eigene Implementierung des Event-Loops vornahm, prüfte es laut Poettering, ob vorhandene Bibliotheken nutzbar wären, fand aber keine, die die Anforderungen erfüllte oder leicht erweiterbar gewesen wäre. So entstand sd-event, das folglich nicht die erste Event-Loop-Schnittstelle ist und auch keine innovativen Konzepte verfolgt, aber dennoch einige Spezialitäten aufweist. Eine davon ist, dass die Ereignisse priorisiert werden, so dass Systemd Ereignisse sortieren und in der korrekten Reihenfolge abarbeiten kann. Eine andere ist, dass es in der Bibliothek nicht zu Situationen kommen kann, wo nicht mehr genug Speicher zur Verfügung steht.

sd-event folgt der Linie von Systemd, Linux-Schnittstellen bestmöglich zu nutzen und sich nicht auf den kleinsten gemeinsamen Nenner zu beschränken, der beispielsweise von POSIX definiert wird. Damit ist sd-event nicht so ohne weiteres auf andere Systeme zu portieren. In seinem Blog erläutert Poettering die Details von sd-event und gibt auch ein Programmierbeispiel.

Auch wenn sd-event jetzt eine offizielle, als stabil deklarierte Schnittstelle von libsystemd ist und anderen Projekten offensteht, ist es nicht unbedingt die beste Wahl für jedes Projekt. So scheidet sd-event aus, wenn ein Projekt portabel sein soll. Für andere Projekte könnte die von sd-event gewählte Priorisierung ein Hindernis sein. Wie Poettering erklärt, lag der Fokus von sd-event bisher nicht auf Höchstleistung, sondern darauf, die Event-Behandlung einfach zu machen. Aufgrund der Priorisierung arbeitet sd-event ziemlich ineffizient, was aber für überschaubare Raten von Events ausreicht. Für externe Entwickler, die relativ einfache Server schreiben wollen, könnte sd-event durchaus interessant sein.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung