US-Präsident Donald Trump hat zusätzliche Zölle in Höhe von 100 Prozent für Importe aus China in die USA angekündigt. Diese würden ab dem 1. November –oder je nach dem weiteren Agieren Chinas auch früher – erhoben, schrieb der Republikaner auf seiner Plattform „Truth Social“ und begründete das Vorhaben mit der aktuellen Handelspolitik Chinas. Zwischen China und den USA herrscht derzeit eine Pause im Zollstreit, der im Frühjahr eskaliert war. Beide Länder hatten im April Importe aus dem jeweils anderen Land mit Aufschlägen von mehr als 100 Prozent belegt. Laut Medienberichten plant China jetzt neue Exportbeschränkungen für seltene Erden.

Aus der Mitteilung von Trump ging nicht hervor, ob die nun angekündigten Zölle eine weitere Erhöhung zu den bereits im Frühjahr angekündigten sind oder wie sie sich zu ihnen verhalten. Trump kündigte in seinem Post zudem Exportkontrollen für jegliche wichtige Software ab dem 1. November an. Genauere Details dazu nannte er nicht. Die sogenannten Exportkontrollen sind meistens Ausfuhrsperren, die von der Regierung in einzelnen Fällen aufgehoben werden können. Dadurch kann ein Land Einfluss darauf nehmen, welche Produkte in andere Staaten gelangen.

Trump stellt Treffen mit Xi infrage

Bereits Stunden zuvor hatte Trump sein geplantes Treffen mit Chinas Präsident Xi Jinping in Südkorea mit Verweis auf den laufenden Handelskonflikt infrage gestellt. Er habe Xi beim Gipfel der Asiatisch-Pazifischen Wirtschaftsgemeinschaft (Apec), der Ende Oktober stattfindet, treffen sollen – „aber jetzt scheint es keinen Grund mehr dafür zu geben“, schrieb der Republikaner am Freitag auf „Truth Social“. Trump begründete seine Aussage damit, dass China angeblich „Briefe an Länder in aller Welt“ geschickt habe, in denen Exportbeschränkungen für seltene Erden und andere Materialien angekündigt wurden. Dies „sei aus dem Nichts gekommen“, könne den Welthandel lahmlegen und vielen Staaten schaden. Die Volksrepublik werde zunehmend „feindselig“, meinte Trump.

In seinem neuen Post spezifizierte er nun, dass China ab November unter anderem Exportkontrollen auf beinahe alle Produkte angekündigt habe, die es herstellt. Die sogenannten seltenen Erden sind wichtig für Elektronik von Smartphones bis Fernsehern sowie in der Autoproduktion und der Rüstungsindustrie. China spielt eine zentrale Rolle bei der weltweiten Versorgung mit den Mineralien. Laut Erhebungen (PDF) der US-Geologie-Behörde USGS, welche dem Innenministerium unterstellt ist, werden rund 70 Prozent aller seltenen Erden in China gefördert.

(nie)

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