In macOS 26 alias Tahoe ist eine neue Kategorie von Launch-Arten hinzugekommen, über die Apple bislang schweigt: Auf LaunchDaemons und LaunchAgents treffen die sogenannten LaunchAngels. Ein entsprechendes Verzeichnis findet sich im Ordner /System/Library, wie Mac & i-Autor und macOS-Experte Howard Oakley entdeckt hat. Es ist noch nicht viel darüber bekannt, was es damit auf sich hat. Klar ist nur, dass die Technik aktuell für drei Apple-eigene Routinen zum Einsatz kommt.

Drei LaunchAngels entdeckt

Während Daemons Hintergrundprozesse sind, die unabhängig agieren, als root bereits vor dem Login laufen, indirekt mit Nutzerprozessen interagieren und von launchd verwaltet werden, laufen Agents zwar unter der Kontrolle von launchd, werden aber vom Nutzer angefordert und interagieren mit Prozessen und Daemons direkt. Die Verwaltung erfolgt über plist-Dateien. Das ist bei Angels genauso.

Aktuell gibt es im System (macOS 26.0.1) drei LaunchAngels: GameOverlayUI, Posterboard und AccessibilityUIServer. Letzteres hilft bei Eingabehilfen und ist direkt mit dem Prozess Accessibility verbunden. GameOverlayUI hat mit dem neuen Game-Overlay-System zu tun, das Apple nun Spielen gönnt. PosterBoard scheint mit der Konfiguration des Lockscreen zu tun zu haben, etwa um dort Kurzbefehle zu platzieren – allerdings scheint es sich dabei noch um einen Test zu enthalten. Der Key „_ExperimentalNonLaunching“ ist hierfür gesetzt.

Geschütztes Verzeichnis

Oakley entdeckte auch, dass alle drei LaunchAngels Referenzen zu RunningBoard haben, einem Life-Cycle-Management-Werkzeug. Diese gibt es für Agents und Daemons bislang nicht. Es bleibt abzuwarten, was Apple mit den LaunchAngels künftig plant – und warum der Hersteller dafür eine neue Kategorie der Startwerkzeuge eingeführt hat. Es gibt derzeit keinen Weg, eigene Angels zu definieren, das Verzeichnis ist geschützt.

Unklar ist auch noch, ob LaunchAngels im Library-Ordner des Nutzers funktionieren oder eben nur systemweit. Letzteres müsste implementiert werden, sofern Apple die Technik für Drittanbieter-Apps als neue Form von Diensten öffnet. Welche Vorteile dies für Entwickler hätte, ist ebenfalls noch nicht gesagt. Durch den Schutz können Angels jedenfalls bislang nicht missbraucht werden.

(bsc)

Mit Boost.Asio gibt es eine altbekannte und dennoch moderne, effiziente und mächtige Bibliothek für die asynchrone Programmierung in C++. Je nach C++-Version können Entwicklerinnen und Entwickler damit auf verschiedene Arten asynchron programmieren, ohne dabei auf komplizierte und fehleranfällige Threading-Mechanismen zurückgreifen zu müssen.

Dieser Artikel bildet den Auftakt einer Reihe zur asynchronen Programmierung in verschiedenen Sprachen – außer Python, das vor Kurzem erst vorgestellt wurde.

Einbinden von Boost.Asio

Auf Linux-Systemen kann man Boost in einer aktuellen Version über die diversen Paketverwaltungen beziehen, unter Ubuntu ist das beispielsweise mit apitude aktuell die Version 1.83:

sudo apt-get install libboost-all-dev

Möchte man die neueste Version (aktuell 1.89) einsetzen oder arbeitet unter Windows, lädt man Boost von der Homepage und baut es selbst. Die entsprechenden Anleitungen finden sich beim Anbieter. Es gibt auch eine baugleiche, reine Asio-Bibliothek – ohne Boost-Abhängigkeiten und mit einem anderen Namespace, die hier aber nicht betrachtet wird.

Context und Event Loop

Grundsätzlich erfordert asynchrone Programmierung ein verwaltendes System, das die API sowie die Mechanismen bereitstellt und den Programmablauf orchestriert. Hier hat sich allgemein der Begriff „Event Loop“ etabliert, Boost.Asio spricht jedoch von „Context“. Der geläufige Ansatz ist es, einen io_context zu verwenden, wie folgendes Beispiel zeigt:

#include 
#include 

int main()
{
    boost::asio::io_context io_context;
    boost::asio::post(io_context, []()
    {
        std::cout << "Hello World from async context!" << std::endl;
    });

    // async execution startet nach dem Aufruf von io_context.run()
    io_context.run(); // run() blockiert bis keine Arbeit mehr vorliegt
}

Listing 1: Einfaches Beispiel zur Verwendung eines Kontextes

post() reiht das Funktionsobjekt, das als Parameter übergeben wird – hier ein Lambda – in die Warteschlange des Kontexts ein und springt sofort zurück.

Der Kontext startet durch den Aufruf von io_context.run() und beginnt nun, die Funktionen der Reihe nach abzuarbeiten. In dem Beispiel wird „Hello World…“ also erst nach io_context.run() ausgegeben.

So initialisiert man das Programm, ohne dass asynchrone Mechanismen auf ein nicht fertig initialisiertes System einwirken. Das vermeidet Fehler, die unter bestimmten Umständen auftreten und schwer zu finden sind, beispielsweise zufällige Nachrichten aus einem anderen Prozess oder eine hohe Auslastung der CPU durch ein anderes Programm.

Die Methode io_context.run() endet, sobald keine Aufgaben mehr vorhanden sind oder io_context.stop() aufgerufen wird. io_context.run() kann man nur einmal pro Thread verwenden. Es ist aber möglich, run() mit dem gleichen io_context aus mehreren Threads aufzurufen.

Im Fall von Listing 1 übergibt der io_context die Arbeit einem Thread, was eine nebenläufige (concurrent) Ausführung bedeutet. In Listing 2 wird io_context.run() von mehreren Threads aus aufgerufen. Übergibt man nun Aufgaben an den Kontext, dann führt dieser die Aufgaben sofort auf einem der Threads aus. Diese Ausführung ist wirklich parallel. Sind alle Threads bereits mit Arbeit ausgelastet, wird die neue Aufgabe in eine Warteschlange eingereiht. Sobald einer der Threads seine Aufgabe abgeschlossen hat, teilt Context ihm Arbeit aus der Warteschlange zu.

#include 
#include 
#include 
#include 

int main()
{
    boost::asio::io_context io_context;

    int n = 4;
    std::vector<:thread> threads(n);
    for (int i = 0; i < n; i++)
    {
        threads[i] = std::thread([&io_context](){ io_context.run();});
    }

    // ... parallel asynchrone Aktionen hier

    for (auto& t : threads)
    {
        if (t.joinable()){ t.join(); }
    }
}

Listing 2: Verwendung von mehreren Threads in einem io_context

Hier erahnt man bereits die Stärke des asynchronen Programmierstils: Die ausführenden Einheiten sind abgelöst von einem konkreten Thread. Asynchrone Programme skalieren nativ und nutzen so viele Ressourcen, wie zur Verfügung stehen.

Nach meiner Erfahrung ist in der Regel ein Thread völlig ausreichend, während mehrere Threads vor allem bei Serversystemen oder ganz speziellen Aufgaben interessant sind, beispielweise zur Berechnung großer Primzahlen oder anderer algorithmischer Probleme. Je mehr Threads (bzw. CPU-Kerne) dem Kontext zur Verfügung stehen, desto mehr Teil-Berechnungen können parallel erfolgen – ohne jede Veränderung des Programms. Entwickler können sich vollständig auf die Funktionalität konzentrieren.

Es ist möglich, das Verhalten von io_context.run() zu verändern, indem man einen work_guard verwendet, wie in Listing 3 zu sehen ist.

#include 
#include 

int main()
{
    boost::asio::io_context io_context;
    boost::asio::executor_work_guard<:asio::io_context::executor_type>
    work_guard(io_context.get_executor());

    boost::asio::post(io_context, []()
    {
        std::cout << "Hello World from async context." << std::endl;
    });

    boost::asio::signal_set signals(io_context, SIGINT, SIGTERM);
    signals.async_wait([&io_context /*&work_guard*/]
        (const boost::system::error_code& ec, int signal)
        {
            io_context.stop(); // bricht sofort alles ab
            // work_guard.reset(); // bricht ab, wenn alles fertig ist
        });

    io_context.run();
}

Listing 3: executor_work_guard kann verhindern, dass run() zurückspringt, wenn context keine Arbeit mehr hat.

Nun springt io_context.run() erst dann zurück, wenn zum einen io_context.stop() aufgerufen wurde – in diesem Fall kommen bereits vorgesehene Aufgaben nicht mehr zur Ausführung und gerade laufende werden mit einem Abbruch-Fehler gestoppt. Zum anderen springt die Funktion zurück, wenn work_guard.reset() aufgerufen wurde – dann arbeitet das Programm alle gerade laufenden und auch alle vorgesehenen Aufgaben noch ab.

Bei letzterem sollten Entwicklerinnen und Entwickler darauf achten, dass sie innerhalb der eingereihten Einheiten keine neuen Aufgaben hinzufügen – denn sonst gerät der Code in eine asynchrone Endlosschleife und io_context.run() wird niemals enden.

Es gibt noch zwei weitere Kontexte in Boost.Asio: thread_pool (siehe Listing 4) und system_context (siehe Listing 5).

#include 
#include 

int main()
{
    boost::asio::thread_pool thread_pool(16);
    boost::asio::post(thread_pool, []()
    {
        std::cout << "Hello World from async context!" << std::endl;
    });

    // thread_pool.stop(); // bricht alle Arbeit im Pool sofort ab
    thread_pool.join(); // wartet bis alle Arbeit abgeschlossen ist

Listing 4: Beispielhafte Verwendung eines thread_pool

Der thread_pool ist eine einfache und empfohlene Alternative, wenn Entwickler mehrere Threads verwenden möchten und keine feingranulare Steuerung der einzelnen Threads benötigen. Eines muss man jedoch berücksichtigen: Im Gegensatz zum io_context startet thread_pool direkt nach der Konstruktion. Ansonsten verhält es sich analog zum io_context: Mit der Methode thread_pool.stop() brechen Entwickler die Ausführung sofort ab, mit thread_pool.join() beendet das Programm aber noch alle Aufgaben. Wurde vorher stop() aufgerufen, dann springt join() sofort zurück.

Der system_context ist von überall immer verfügbar – er muss nicht gestartet oder gestoppt werden. Er ist eine gute Wahl, wenn Entwickler an einem bestimmten Punkt ohne großen Aufwand und Vorbereitung – aber auch ohne eigene Steuerung – asynchrone Operationen ausführen möchten.

#include 
#include 

int main()
{
    boost::asio::system_context system_context;
    boost::asio::post(system_context, []()
    {
        std::cout << "Hello World from async context!" << std::endl;
    });
}

Listing 5: Beispielhafte Verwendung von system_context

Die Europäische Kommission verdächtigt Apple, Snapchat sowie Google und Youtube, Kinder auf ihren Plattformen nicht genug zu schützen. Die Brüsseler Behörde verlangt von den Tech-Konzernen daher nun Auskünfte zu ihren Sicherheitsvorkehrungen, wie die zuständige Kommissionsvizepräsidentin Henna Virkkunen bei einem Treffen der EU-Digitalminister im dänischen Horsens mitteilte. Grundlage für die verpflichtende Forderung nach Informationen ist das Gesetz über digitale Dienste (Digital Services Act, kurz DSA).

Bei der Videoplattform Youtube, die zum Google-Konzern gehört, hegt die EU-Kommission den Verdacht, dass Altersbeschränkungen für Kinder und Jugendliche zu leicht zu umgehen seien. Zudem soll geprüft werden, inwiefern Youtube mit seinen Algorithmen Kinder süchtig machen könnte.

Von der Leyen hatte App-Entwicklern zuletzt vorgeworfen, Kinder aus Profitinteressen mit den Algorithmen ihrer Produkte süchtig zu machen. Sie kündigte an, bis Ende des Jahres eine Expertengruppe einzurichten, die über das weitere Vorgehen in der EU beraten soll.

Kaufen Kinder auf Snapchat Drogen?

Die Brüsseler Behörde will zudem klären, ob Minderjährige auf den Software-Plattformen von Apple („App Store“) und Google („Google Play“) Glücksspiele, wie etwa Apps für Online-Kasinos, herunterladen und spielen können.

Auf dem sozialen Netzwerk Snapchat könnte es Minderjährigen laut EU möglich sein, Drogen zu kaufen. Außerdem verdächtigen die europäischen Regelhüter das Unternehmen, selbst festgelegte Altersgrenzen nicht zu berücksichtigen. So gelinge es Kindern unter 13, die App zu nutzen, obwohl dies in den Allgemeinen Geschäftsbedingungen (AGB) verboten sei.

Mit den Auskunftsersuchen eröffnet die EU noch kein Verfahren gegen die Tech-Konzerne. Die Unternehmen können jetzt erläutern, wie sie verhindern, dass ihre Produkte Kindern schaden. Sie haben auch die Möglichkeit, Änderungen an ihren Diensten vorzunehmen, um den Verdacht auszuräumen.

Sieht sich die EU-Kommission jedoch bestätigt, könnte sie ein Verfahren wegen unzureichenden Kinder- und Jugendschutzes eröffnen. Gegen den Facebook-Konzern Meta läuft ein solches Verfahren bereits seit vergangenem Jahr. Im Juli hatte die Europäische Kommission einen Leitfaden zu den Kinderschutzgesetzen veröffentlicht, der Unternehmen bei der Einhaltung helfen sollte.

Wieso die USA das Gesetz über digitale Dienste kritisieren

Das Gesetz über digitale Dienste (DSA) soll unter anderem sicherstellen, dass Plattformen illegale Inhalte von ihren Seiten schneller entfernen als bislang. Nutzern wird es wiederum leichter gemacht, solche Inhalte zu melden. Grundsätzlich müssen große Dienste mehr Regeln befolgen als kleine.

In der Vergangenheit hatte das Gesetz auch für Probleme in der Beziehung zwischen der EU und den Vereinigten Staaten gesorgt. Die US-Regierung unter Präsident Donald Trump kritisierte europäische Digitalgesetze wie das DSA als wettbewerbsfeindlich. Meta-Chef Mark Zuckerberg hatte in Bezug auf die EU-Regeln von „institutionalisierter Zensur“ gesprochen.

EU erhöht Druck auf digitale Konzerne beim Kinderschutz

Brüssel legte in den vergangenen Monaten vermehrt ein Augenmerk darauf, welche Erfahrungen Kinder und Jugendliche online machen. EU-Kommissionspräsidentin Ursula von der Leyen hatte sich zuletzt überraschend für eine Altersgrenze in den sozialen Netzwerken ausgesprochen. Die deutsche Politikerin verglich dabei mögliche Vorgaben für soziale Medien mit denen für Tabak und Alkohol.

Außerdem soll ein digitaler Alterscheck künftig verhindern, dass Kinder und Jugendliche auf Pornografie und andere nicht altersgerechte Inhalte im Internet zugreifen können. Dafür testen derzeit mehrere Mitgliedstaaten einen von der EU mitentwickelten Prototyp.

(afl)