Asynchrone Geschäftslogik heutzutage

Kurzum:

• Der Proof ist bereits in C ++ , JS und PHP implementiert, geeignet für Java .
• Schneller als Coroutine und Promise, mehr Funktionen.
• Es ist kein separater Software-Stack erforderlich.
• Befreundet alle Sicherheits- und Debugging-Tools.
• Es funktioniert auf jeder Architektur und erfordert keine speziellen Compiler-Flags.

• Schau zurück
• FutoIn AsyncSteps - eine Alternative zu Coroutinen
• Zu den Zahlen

Schau zurück

Zu Beginn des Computers gab es einen einzigen Kontrollfluss mit Blockierung der Eingabe / Ausgabe. Dann wurden Eisenunterbrechungen hinzugefügt. Jetzt können Sie langsame und unvorhersehbare Geräte effektiv verwenden.

Mit dem Wachstum der Eisenkapazitäten und seiner geringen Verfügbarkeit wurde es notwendig, mehrere Aufgaben gleichzeitig auszuführen, was Hardware-Unterstützung bot. Es gab also isolierte Prozesse mit Unterbrechungen, die in Form von Signalen vom Eisen abstrahiert wurden.

Die nächste Evolutionsstufe war Multithreading, das auf der Grundlage derselben Prozesse implementiert wurde, jedoch mit gemeinsamem Zugriff auf Speicher und andere Ressourcen. Dieser Ansatz hat seine Grenzen und einen erheblichen Aufwand für den Wechsel zu einem sicheren Betriebssystem.

Für die Kommunikation zwischen Prozessen und sogar verschiedenen Maschinen wurde vor mehr als 40 Jahren die Abstraktion Promise / Future vorgeschlagen.

Die Benutzeroberflächen und das derzeit lächerliche 10K-Client-Problem haben zur Blütezeit der Event Loop-, Reactor- und Proactor-Ansätze geführt, die eher ereignisorientiert sind als eine klare, konsistente Geschäftslogik.

Schließlich kamen wir zur modernen Coroutine (Coroutine), die im Wesentlichen eine Emulation von Flüssen über den oben beschriebenen Abstraktionen mit den entsprechenden technischen Einschränkungen und dem deterministischen Kontrolltransfer ist.

Um Ereignisse, Ergebnisse und Ausnahmen zu vermitteln, kehrten alle zum gleichen Konzept von Versprechen / Zukunft zurück. Einige Büros haben beschlossen, etwas anders zu benennen - "Aufgabe".

Am Ende versteckten sie alles in einem wunderschönen async/await Paket, das je nach Technologie Unterstützung durch Compiler oder Übersetzer erfordert.

Probleme mit aktuellen asynchronen Geschäftslogiksituationen

Betrachten Sie nur Coroutinen und Promise, dekoriert mit async/await , as Das Vorhandensein von Problemen in älteren Ansätzen bestätigt den Evolutionsprozess selbst.

Diese beiden Begriffe sind nicht identisch. Zum Beispiel gibt es in ECMAScript keine Coroutinen, aber es gibt eine syntaktische Erleichterung für die Verwendung von Promise , die wiederum nur die Arbeit mit der Callback-Hölle organisiert. In der Tat gehen Scripting-Engines wie V8 noch weiter und nehmen spezielle Optimierungen für reine async/await Funktionen und Aufrufe vor.

Experten co_async/co_await , das hier auf der Ressource nicht in C ++ 17 co_async/co_await , aber der Druck der Software-Riesen-Coroutinen kann im Standard genau in ihrer Form erscheinen. In der Zwischenzeit ist die traditionell anerkannte Lösung Boost.Context , Boost.Fiber und Boost.Coroutine2 .

In Java gibt es auf Sprachebene immer noch kein async/await Warten , aber es gibt Lösungen wie EA Async , die wie Boost.Context für jede Version der JVM und des Codebytes angepasst werden müssen.

Go hat seine eigenen Coroutinen, aber wenn man sich die Artikel und Fehlerberichte offener Projekte genau ansieht, stellt sich heraus, dass hier nicht alles so reibungslos ist. Vielleicht ist es keine gute Idee, die Coroutine-Schnittstelle als verwaltete Entität zu verlieren.

Meinung des Autors: Bare-Metal-Coroutinen sind gefährlich

Persönlich hat der Autor wenig gegen Coroutinen in dynamischen Sprachen, aber er ist äußerst vorsichtig, wenn er auf der Ebene des Maschinencodes mit dem Stapel flirtet.

Ein paar Punkte:

1. Stapel erforderlich:
   
   • Der Stapel auf dem Haufen hat eine Reihe von Nachteilen: Probleme bei der rechtzeitigen Bestimmung des Überlaufs, Schäden durch Nachbarn und andere Zuverlässigkeits- / Sicherheitsprobleme,
   • Ein geschützter Stapel erfordert mindestens eine Seite physischen Speichers, eine bedingte Seite und zusätzlichen Overhead für jeden Aufruf von async Funktionen: 4 + KB (Minimum) + erhöhte Systemlimits,
   • Letztendlich kann es sein, dass ein erheblicher Teil des für die Stapel zugewiesenen Speichers während der Ausfallzeit der Coroutine nicht verwendet wird.
2. Es ist notwendig, eine komplexe Logik zum Speichern, Wiederherstellen und Löschen des Status von Coroutinen zu implementieren:
   
   • für jeden Fall von Prozessorarchitektur (auch Modelle) und binärer Schnittstelle (ABI): Beispiel :
   • Neue oder optionale Architekturfunktionen führen zu potenziell latenten Problemen (z. B. Intel TSX, ARM-Co-Prozessoren oder MIPS).
   • andere potenzielle Probleme aufgrund der geschlossenen Dokumentation proprietärer Systeme (Boost-Dokumentation bezieht sich darauf).
3. Mögliche Probleme mit dynamischen Analysetools und mit der Sicherheit im Allgemeinen:
   
   • Zum Beispiel ist die Integration mit Valgrind aufgrund der gleichen Sprungstapel erforderlich.
   • Es ist schwer, für Virostatika zu sprechen, aber wahrscheinlich gefällt es ihnen am Beispiel von Problemen mit JVM in der Vergangenheit nicht wirklich.
   • Ich bin sicher, dass neue Arten von Angriffen auftreten und Schwachstellen im Zusammenhang mit der Implementierung von Coroutinen aufgedeckt werden.

Meinung des Autors: Generatoren und yield grundlegendes Übel

Dieses scheinbar von Dritten stammende Thema steht in direktem Zusammenhang mit dem Konzept der Coroutinen und der Eigenschaft "Fortfahren".

Kurz gesagt, für jede Sammlung muss ein vollständiger Iterator vorhanden sein. Warum ein zugeschnittenes Iterator-Generator-Problem erstellt wird, ist nicht klar. Zum Beispiel ist ein Fall mit range() in Python eher eine exklusive Demonstration als eine Entschuldigung für technische Komplikationen.

Wenn der Fall ein unendlicher Generator ist, ist die Logik seiner Implementierung elementar. Warum zusätzliche technische Schwierigkeiten verursachen, um einen endlosen Zyklus fortzusetzen?

Die einzige vernünftige Rechtfertigung, die später von Befürwortern von Coroutinen gegeben wurde, sind alle Arten von Stream-Parsern mit umgekehrter Kontrolle. Tatsächlich handelt es sich hierbei um einen engen Spezialfall zur Lösung einzelner Probleme auf Bibliotheksebene, nicht um die Geschäftslogik von Anwendungen. Gleichzeitig gibt es eine elegante, einfache und aussagekräftigere Lösung durch endliche Zustandsmaschinen. Der Bereich dieser technischen Probleme ist viel kleiner als der Bereich der alltäglichen Geschäftslogik.

Tatsächlich wird das zu lösende Problem von einem Finger aus gelöst und erfordert relativ ernsthafte Anstrengungen für die anfängliche Implementierung und langfristige Unterstützung. So sehr, dass einige Projekte möglicherweise ein Verbot der Verwendung von Coroutinen auf Maschinencode-Ebene einführen, das dem Beispiel eines Verbots von goto oder der Verwendung der dynamischen Speicherzuweisung in einzelnen Branchen folgt.

Meinung der Autoren: Das async/await Promise-Modell von ECMAScript ist zuverlässiger, muss jedoch angepasst werden

Im Gegensatz zu fortlaufenden Coroutinen werden in diesem Modell die Codeteile heimlich in nicht unterbrechbare Blöcke unterteilt, die als anonyme Funktionen ausgelegt sind. In C ++ ist dies aufgrund der Besonderheiten der Speicherverwaltung nicht ganz geeignet. Ein Beispiel:

 struct SomeObject { using Value = std::vector<int>; Promise funcPromise() { return Promise.resolved(value_); } void funcCallback(std::function<void()> &&cb, const Value& val) { somehow_call_later(cb); } Value value_; }; Promise example() { SomeObject some_obj; return some_obj.funcPromise() .catch([](const std::exception &e){ // ... }) .then([&](SomeObject::value &&val){ return Promise([&](Resolve&& resolve, Reject&&){ some_obj.funcCallback(resolve, val); }); }); } 

Erstens wird some_obj beim Beenden von example() und vor dem Aufrufen von Lambda-Funktionen zerstört.

Zweitens sind Lambda-Funktionen mit Erfassungsvariablen oder Referenzen Objekte und fügen heimlich Kopieren / Verschieben hinzu, was sich negativ auf die Leistung bei einer großen Anzahl von Erfassungen und die Notwendigkeit auswirken kann, während der Typlöschung in der üblichen std::function Speicher auf dem Heap zuzuweisen.

Drittens wurde die Promise Schnittstelle selbst eher nach dem Konzept des "Versprechens" des Ergebnisses als nach der konsequenten Ausführung der Geschäftslogik konzipiert.

Eine schematische, NICHT optimale Lösung könnte ungefähr so ​​aussehen:

 Promise example() { struct LocalContext { SomeObject some_obj; }; auto ctx = std::make_shared<LocalContext>(); return some_obj.funcPromise() .catch([](const std::exception &e){ // ... }) .then([ctx](SomeObject::Value &&val){ struct LocalContext2 { LocalContext2(std::shared_ptr<LocalContext> &&ctx, SomeObject::Value &&val) : ctx(ctx), val(val) {} std::shared_ptr<LocalContext> ctx; SomeObject::Value val; }; auto ctx2 = std::make_shared<LocalContext2>( std::move(ctx), std::forward<SomeObject::Value>(val) ); return Promise([ctx2](Resolve&& resolve, Reject&&){ ctx2->ctx->some_obj.funcCallback([ctx2, resolve](){ resolve(); }, val); }); }); } 

Hinweis: std::move anstelle von std::shared_ptr nicht geeignet, da nicht mehrere Lambdas gleichzeitig übertragen werden können und ihre Größe zunimmt.

Mit der Hinzufügung von async/await asynchrone Schrecken in einen verdaulichen Zustand:

 async void example() { SomeObject some_obj; try { SomeObject::Value val = await some_obj.func(); } catch (const std::exception& e) ( // ... } // Capture "async context" return Promise([async](Resolve&& resolve, Reject&&){ some_obj.funcCallback([async](){ resolve(); }, val); }); } 

Meinung des Autors: Coroutine Planer ist eine Pleite

Einige Kritiker bezeichnen das Fehlen eines Schedulers und den "unehrlichen" Einsatz von Prozessorressourcen als Problem. Ein möglicherweise schwerwiegenderes Problem ist die Datenlokalität und die effiziente Nutzung des Prozessor-Cache.

Zum ersten Problem: Die Priorisierung auf der Ebene einzelner Coroutinen sieht nach einem großen Aufwand aus. Stattdessen können sie gemeinsam für eine bestimmte einheitliche Aufgabe bearbeitet werden. Dies ist, was Verkehrsströme tun.

Dies ist möglich, indem separate Instanzen der Ereignisschleife mit eigenen "Eisen" -Threads erstellt und auf Betriebssystemebene geplant werden. Die zweite Möglichkeit besteht darin, Coroutinen mit einem relativ primitiven (Mutex, Throttle) Primitiv in Bezug auf Wettbewerb und / oder Leistung zu synchronisieren.

Die asynchrone Programmierung macht die Prozessorressourcen nicht gummiartig und erfordert absolut normale Einschränkungen hinsichtlich der Anzahl gleichzeitig verarbeiteter Aufgaben und Einschränkungen der Gesamtausführungszeit.

Der Schutz gegen langes Blockieren auf einer Coroutine erfordert die gleichen Maßnahmen wie bei Rückrufen - um das Blockieren von Systemaufrufen und lange Datenverarbeitungszyklen zu vermeiden.

Das zweite Problem erfordert Nachforschungen, aber zumindest die Coroutine-Stapel selbst und die Details der Future / Promise-Implementierung verletzen bereits die Lokalität der Daten. Es besteht die Möglichkeit, die Ausführung derselben Coroutine fortzusetzen, wenn Future bereits eine Rolle spielt. Ein bestimmter Mechanismus ist erforderlich, um die Ausführungszeit oder die Anzahl solcher Fortsetzungen zu berechnen, um zu verhindern, dass eine Coroutine die gesamte Prozessorzeit erfasst. Abhängig von der Größe des Prozessor-Cache und der Anzahl der Threads kann dies entweder kein oder nur ein sehr zweifaches Ergebnis liefern.

Es gibt noch einen dritten Punkt: Viele Implementierungen von Coroutine-Schedulern ermöglichen die Ausführung auf verschiedenen Prozessorkernen, was im Gegenteil zu Problemen aufgrund der obligatorischen Synchronisierung beim Zugriff auf gemeinsam genutzte Ressourcen führt. Im Fall eines einzelnen Ereignisschleifenstroms ist eine solche Synchronisation nur auf logischer Ebene erforderlich, da Jeder synchrone Rückrufblock funktioniert garantiert ohne Rennen mit anderen.

Meinung des Autors: Alles ist gut in Maßen

Das Vorhandensein von Threads in modernen Betriebssystemen negiert nicht die Verwendung einzelner Prozesse. Durch die Verarbeitung einer großen Anzahl von Clients in der Ereignisschleife wird die Verwendung isolierter "Eisen" -Threads für andere Anforderungen nicht negiert.

In jedem Fall erschweren Coroutinen und verschiedene Varianten von Ereignisschleifen den Debugging-Prozess ohne die erforderliche Unterstützung in den Tools, und mit lokalen Variablen auf dem Coroutine-Stapel wird alles noch schwieriger - es gibt praktisch keine Möglichkeit, an sie heranzukommen.

FutoIn AsyncSteps - eine Alternative zu Coroutinen

Wir stützen uns auf das bereits etablierte Event-Loop-Muster und die Organisation von Rückrufschemata nach dem Promise-Typ ECMAScript (JavaScript).

In Bezug auf die Ausführungsplanung interessieren uns folgende Aktivitäten aus Event Loop:

1. Handle immediate(callack) die einen sauberen Aufrufstapel erfordern.
2. Zurückgestellter Rückruf Handle deferred(delay, callback) Rückruf Handle deferred(delay, callback) .
3. handle.cancel() das Rückruf- handle.cancel() .

So erhalten wir eine Schnittstelle namens AsyncTool , die auf viele Arten implementiert werden kann, auch zusätzlich zu bestehenden bewährten Entwicklungen. Er hat keine direkte Beziehung zum Schreiben von Geschäftslogik, daher werden wir nicht auf weitere Details eingehen.

Baum der Schritte:

Im AsyncSteps-Konzept wird ein abstrakter Baum synchroner Schritte aufgereiht und ausgeführt, indem tief in die Erstellungssequenz hineingegangen wird. Die Schritte jeder tieferen Ebene werden dynamisch festgelegt, wenn eine solche Passage abgeschlossen ist.

Die gesamte Interaktion erfolgt über eine einzige AsyncSteps Schnittstelle, die AsyncSteps Konvention als erster Parameter an jeden Schritt übergeben wird. Konventionell ist der Parametername asi oder veraltet as . Mit diesem Ansatz können Sie die Verbindung zwischen einer bestimmten Implementierung und dem Schreiben von Geschäftslogik in Plugins und Bibliotheken fast vollständig trennen.

In kanonischen Implementierungen erhält jeder Schritt eine eigene Instanz eines Objekts, das AsyncSteps implementiert, wodurch logische Fehler bei der Verwendung der Schnittstelle rechtzeitig verfolgt werden können.

Abstraktes Beispiel:

  asi.add( // Level 0 step 1 func( asi ){ print( "Level 0 func" ) asi.add( // Level 1 step 1 func( asi ){ print( "Level 1 func" ) asi.error( "MyError" ) }, onerror( asi, error ){ // Level 1 step 1 catch print( "Level 1 onerror: " + error ) asi.error( "NewError" ) } ) }, onerror( asi, error ){ // Level 0 step 1 catch print( "Level 0 onerror: " + error ) if ( error strequal "NewError" ) { asi.success( "Prm", 123, [1, 2, 3], true) } } ) asi.add( // Level 0 step 2 func( asi, str_param, int_param, array_param ){ print( "Level 0 func2: " + param ) } ) 

Ausführungsergebnis:

  Level 0 func 1 Level 1 func 1 Level 1 onerror 1: MyError Level 0 onerror 1: NewError Level 0 func 2: Prm 

Synchron würde es so aussehen:

  str_res, int_res, array_res, bool_res // undefined try { // Level 0 step 1 print( "Level 0 func 1" ) try { // Level 1 step 1 print( "Level 1 func 1" ) throw "MyError" } catch( error ){ // Level 1 step 1 catch print( "Level 1 onerror 1: " + error ) throw "NewError" } } catch( error ){ // Level 0 step 1 catch print( "Level 0 onerror 1: " + error ) if ( error strequal "NewError" ) { str_res = "Prm" int_res = 123 array_res = [1, 2, 3] bool_res = true } else { re-throw } } { // Level 0 step 2 print( "Level 0 func 2: " + str_res ) } 

Die maximale Nachahmung des herkömmlichen synchronen Codes ist sofort sichtbar, was die Lesbarkeit verbessern soll.

Aus Sicht der Geschäftslogik wächst mit der Zeit ein großer Teil der Anforderungen , aber wir können ihn in leicht verständliche Teile unterteilen. Im Folgenden wird das Ergebnis eines vierjährigen Laufens in der Praxis beschrieben.

Kernlaufzeit-APIs:

1. add(func[, onerror]) - Nachahmung des try-catch .
2. success([args...]) - ein expliziter Hinweis auf den erfolgreichen Abschluss:
   
   • standardmäßig impliziert
   • kann die Ergebnisse an den nächsten Schritt übergeben.
3. error(code[, reason) - Unterbrechung der Ausführung mit einem Fehler:
   
   • code - hat einen Zeichenfolgentyp zur besseren Integration in Netzwerkprotokolle in der Microservice-Architektur.
   • reason - eine willkürliche Erklärung für eine Person.
4. state() - ein Analogon zu Thread Local Storage. Vordefinierte assoziative Schlüssel:
   
   • error_info - Erklärung des letzten Fehlers für eine Person,
   • last_exception - Zeiger auf das Objekt der letzten Ausnahme,
   • async_stack - ein Stapel asynchroner Aufrufe, async_stack die Technologie dies zulässt,
   • Der Rest wird vom Benutzer festgelegt.

Das vorherige Beispiel enthält bereits echten C ++ - Code und einige zusätzliche Funktionen:

 #include <futoin/iasyncsteps.hpp> using namespace futoin; void some_api(IAsyncSteps& asi) { asi.add( [](IAsyncSteps& asi) { std::cout << "Level 0 func 1" << std::endl; asi.add( [](IAsyncSteps& asi) { std::cout << "Level 1 func 1" << std::endl; asi.error("MyError"); }, [](IAsyncSteps& asi, ErrorCode code) { std::cout << "Level 1 onerror 1: " << code << std::endl; asi.error("NewError", "Human-readable description"); } ); }, [](IAsyncSteps& asi, ErrorCode code) { std::cout << "Level 0 onerror 1: " << code << std::endl; if (code == "NewError") { // Human-readable error info assert(asi.state().error_info == "Human-readable description"); // Last exception thrown is also available in state std::exception_ptr e = asi.state().last_exception; // NOTE: smart conversion of "const char*" asi.success("Prm", 123, std::vector<int>({1, 2, 3}, true)); } } ); asi.add( [](IAsyncSteps& asi, const futoin::string& str_res, int int_res, std::vector<int>&& arr_res) { std::cout << "Level 0 func 2: " << str_res << std::endl; } ); } 

API zum Erstellen von Schleifen:

1. loop( func, [, label] ) - Schritt mit einem unendlich wiederholbaren Körper.
2. forEach( map|list, func [, label] ) - Schritt-Iteration des Auflistungsobjekts.
3. repeat( count, func [, label] ) - Schritt-Iteration angegeben.
4. break( [label] ) ist ein Analogon zum herkömmlichen Loop-Interrupt.
5. continue( [label] ) ist ein Analogon zur traditionellen Schleifenfortsetzung mit einer neuen Iteration.

Die Spezifikation bietet alternative Namen breakLoop , continueLoop und andere im Falle eines Konflikts mit reservierten Wörtern.

C ++ Beispiel:

  asi.loop([](IAsyncSteps& asi) { // infinite loop asi.breakLoop(); }); asi.repeat(10, [](IAsyncSteps& asi, size_t i) { // range loop from i=0 till i=9 (inclusive) asi.continueLoop(); }); asi.forEach( std::vector<int>{1, 2, 3}, [](IAsyncSteps& asi, size_t i, int v) { // Iteration of vector-like and list-like objects }); asi.forEach( std::list<futoin::string>{"1", "2", "3"}, [](IAsyncSteps& asi, size_t i, const futoin::string& v) { // Iteration of vector-like and list-like objects }); asi.forEach( std::map<futoin::string, futoin::string>(), [](IAsyncSteps& asi, const futoin::string& key, const futoin::string& v) { // Iteration of map-like objects }); std::map<std::string, futoin::string> non_const_map; asi.forEach( non_const_map, [](IAsyncSteps& asi, const std::string& key, futoin::string& v) { // Iteration of map-like objects, note the value reference type }); 

API zur Integration mit externen Ereignissen:

1. setTimeout( timeout_ms ) - setTimeout( timeout_ms ) nach einem Timeout einen Timeout Fehler aus, wenn der Schritt und sein Teilbaum die Ausführung nicht abgeschlossen haben.
2. setCancel( handler ) - setCancel( handler ) , der aufgerufen wird, wenn der Thread vollständig abgebrochen wird und wenn der Stapel asynchroner Schritte während der Fehlerverarbeitung erweitert wird.
3. waitExternal() - ein einfaches Warten auf ein externes Ereignis.
   
   • Hinweis: Die Verwendung ist nur in Technologien mit einem Garbage Collector sicher.

Ein Aufruf einer dieser Funktionen macht einen expliziten Aufruf von success() erforderlich.

C ++ Beispiel:

  asi.add([](IAsyncSteps& asi) { auto handle = schedule_external_callback([&](bool err) { if (err) { try { asi.error("ExternalError"); } catch (...) { // pass } } else { asi.success(); } }); asi.setCancel([=](IAsyncSteps& asi) { external_cancel(handle); }); }); asi.add( [](IAsyncSteps& asi) { // Raises Timeout error after specified period asi.setTimeout(std::chrono::seconds{10}); asi.loop([](IAsyncSteps& asi) { // infinite loop }); }, [](IAsyncSteps& asi, ErrorCode code) { if (code == futoin::errors::Timeout) { asi(); } }); 

ECMAScript-Beispiel:

 asi.add( (asi) => { asi.waitExternal(); // disable implicit success() some_obj.read( (err, data) => { if (!asi.state) { // ignore as AsyncSteps execution got canceled } else if (err) { try { asi.error( 'IOError', err ); } catch (_) { // ignore error thrown as there are no // AsyncSteps frames on stack. } } else { asi.success( data ); } } ); } ); 

Future / Promise Integration API:

1. await(promise_future[, on_error]) - Warten auf Zukunft / Versprechen als Schritt.
2. promise() - verwandelt den gesamten Ausführungsfluss in Future / Promise, das anstelle von execute() .

C ++ Beispiel:

  [](IAsyncSteps& asi) { // Proper way to create new AsyncSteps instances // without hard dependency on implementation. auto new_steps = asi.newInstance(); new_steps->add([](IAsyncSteps& asi) {}); // Can be called outside of AsyncSteps event loop // new_steps.promise().wait(); // or // new_steps.promise<int>().get(); // Proper way to wait for standard std::future asi.await(new_steps->promise()); // Ensure instance lifetime asi.state()["some_obj"] = std::move(new_steps); }; 

API zur Steuerung des Geschäftslogikflusses:

1. AsyncSteps(AsyncTool&) ist ein Konstruktor, der einen Ausführungsthread an eine bestimmte Ereignisschleife bindet.
2. execute() - Startet den Ausführungsthread.
3. cancel() - Bricht den Ausführungsthread ab.

Hier ist bereits eine spezifische Schnittstellenimplementierung erforderlich.

C ++ Beispiel:

 #include <futoin/ri/asyncsteps.hpp> #include <futoin/ri/asynctool.hpp> void example() { futoin::ri::AsyncTool at; futoin::ri::AsyncSteps asi{at}; asi.loop([&](futoin::IAsyncSteps &asi){ // Some infinite loop logic }); asi.execute(); std::this_thread::sleep_for(std::chrono::seconds{10}); asi.cancel(); // called in d-tor by fact } 

andere APIs:

1. newInstance() - Ermöglicht das Erstellen eines neuen Ausführungsthreads ohne direkte Abhängigkeit von der Implementierung.
2. sync(object, func, onerror) - das gleiche, jedoch mit Synchronisation relativ zu einem Objekt, das die entsprechende Schnittstelle implementiert.
3. parallel([on_error]) - spezielles add() , dessen Teilschritte separate AsyncSteps-Streams sind:
   
   • Alle Threads haben den gemeinsamen state() .
   • Der übergeordnete Thread setzt die Ausführung nach Abschluss aller untergeordneten Threads fort
   • Ein nicht erfasster Fehler in einem untergeordneten Element löscht sofort alle anderen untergeordneten Threads.

C ++ - Beispiele:

  #include <futoin/ri/mutex.hpp> using namespace futoin; ri::Mutex mtx_a; void sync_example(IAsyncSteps& asi) { asi.sync(mtx_a, [](IAsyncSteps& asi) { // synchronized section asi.add([](IAsyncSteps& asi) { // inner step in the section // This synchronization is NOOP for already // acquired Mutex. asi.sync(mtx_a, [](IAsyncSteps& asi) { }); }); }); } void parallel_example(IAsyncSteps& asi) { using OrderVector = std::vector<int>; asi.state("order", OrderVector{}); auto& p = asi.parallel([](IAsyncSteps& asi, ErrorCode) { // Overall error handler asi.success(); }); p.add([](IAsyncSteps& asi) { // regular flow asi.state<OrderVector>("order").push_back(1); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(4); }); }); p.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(2); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(5); asi.error("SomeError"); }); }); p.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(3); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order").push_back(6); }); }); asi.add([](IAsyncSteps& asi) { asi.state<OrderVector>("order"); // 1, 2, 3, 4, 5 }); }; 

Standardprimitive für die Synchronisation

1. Mutex - schränkt die gleichzeitige Ausführung von N Threads mit einer Warteschlange in Q , standardmäßig N=1, Q=unlimited .
2. Throttle - begrenzt die Anzahl der Eingänge N in Periode P mit einer Warteschlange in Q , standardmäßig N=1, P=1s, Q=0 .
3. Limiter ist eine Kombination aus Mutex und Throttle , die normalerweise bei der Eingabe der Verarbeitung externer Anforderungen und beim Aufrufen externer Systeme zum Zwecke eines stabilen Betriebs unter Last verwendet wird.

Bei DefenseRejected Warteschlangenlimits wird ein DefenseRejected Fehler DefenseRejected , dessen Bedeutung aus der Limiter Beschreibung hervorgeht.

Hauptvorteile

Das Konzept von AsyncSteps war kein Selbstzweck, sondern entstand aus der Notwendigkeit einer kontrollierten asynchronen Ausführung von Programmen hinsichtlich Zeitlimit, Abbruch und Gesamtkonnektivität einzelner Rückrufe. Keine der universellen Lösungen zu dieser Zeit und bietet jetzt die gleiche Funktionalität. Deshalb:

FTN12 — .

setCancel() — . , . RAII atexit() .

cancel() — , . SIGTERM pthread_cancel() , .

setTimeout() — . , "Timeout".

— FutoIn AsyncSteps .

— ABI , . Embedded MMU.

Intel Xeon E3-1245v2/DDR1333 Debian Stretch .

:

1. Boost.Fiber protected_fixedsize_stack .
2. Boost.Fiber pooled_fixedsize_stack .
3. FutoIn AsyncSteps .
4. FutoIn AsyncSteps ( FUTOIN_USE_MEMPOOL=false ).
   
   • futoin::IMemPool .
5. FutoIn NitroSteps<> — .
   
   • .

Boost.Fiber :

1. 1 . .
2. 30 . 1 . .
   
   • 30 . mmap()/mprotect() boost::fiber::protected_fixedsize_stack .
   • .
3. 30 . 10 . .
   
   • "" .

"" , .. , . . .

GCC 6.3.0. lang tcmalloc , .

GitHub GitLab .

1.

— .

Boost.Fiber - , pooled_fixedsize_stack , AsyncSteps.

2.

— .

, . , — .

3.

— .

, Boost.Fiber AsyncSteps, NitroSteps.

( RSS)

— .

, Boost.Fiber .

: Node.js

- Promise : + 10 . . 10 . JIT NODE_ENV=production , @futoin/optihelp .

GitHub GitLab . Node.js v8.12.0 v10.11.0, FutoIn CID .

— .

async/await ? , V8 Node.js v10 .

, Promise async/await Node.js Event Loop. ( ), FutoIn AsyncSteps .

AsyncSteps Node.js Event Loop async/await - Node.js v10.

, ++ — . , Node.js 10 .

Schlussfolgerungen

C++, FutoIn AsyncSteps Boost.Fiber , Boost.Fiber mmap()/mprotect .

, - , . .

FutoIn AsyncSteps JavaScript async/await Node.js v10.

, -, . .

- "" . — API.

Fazit

, FutoIn AsyncSteps , "" async/await . , . Promise ECMAScript, AsyncSteps "" .

. AsyncSteps NitroSteps .

, - .

Java/JVM — . .

, GitHub / GitLab .