___ qstnhdr ___ Blockierung von Kanälen und asynchronen Nachrichtenübergaben
___ tag123erlang ___ Erlang ist eine general purpose, garbage-collected Programmiersprache und Laufzeitumgebung mit integrierter Unterstützung für Parallelität, Verteilung und Fehlertoleranz.
___ answer2240157 ___
Allgemein gesprochen handelt es sich hierbei um unbegrenzte Warteschlangen gegen begrenzte Warteschlangen. Ein stapelloser Kanal kann als Spezialfall einer Warteschlange mit der Größe 0 betrachtet werden.
Begrenzte Warteschlangen neigen dazu, sich zu blockieren. Zwei Threads / Prozesse, die versuchen, eine Nachricht zu senden, beide mit einer vollständigen Warteschlange.
Unbegrenzte Warteschlangen haben einen subtileren Fehler. Ein großes Postfach erfüllt die Latenzanforderungen nicht, wie Sie bereits erwähnt haben. Gehe weit genug und es wird schließlich überlaufen; Es gibt keine unendliche Speicherkapazität, also ist es nur eine beschränkte Warteschlange mit einem riesigen Limit, das den Prozess abbricht, wenn er voll ist.
Was ist das Beste? Das ist schwer zu sagen. Es gibt keine einfachen Antworten hier.
___ antwort2240486 ___
Meine Erfahrung mit Erlang-Programmierung ist, dass Sie, wenn Sie eine hohe Nachrichtenrate erwarten (dh einen schnelleren Produzenten als einen Verbraucher), Ihre eigene Flusskontrolle hinzufügen. Ein einfaches Szenario
- Der Verbraucher wird: Nachricht senden, auf Bestätigung warten und dann wiederholen.
- Der Produzent wird: auf eine Nachricht warten, eine Bestätigung senden, wenn eine Nachricht empfangen und verarbeitet wurde, und dann wiederholen.
Man kann es auch invertieren, der Produzent wartet darauf, dass der Konsument kommt und greift auf die nächsten verfügbaren Nachrichten.
Diese Ansätze und andere Flusskontrolle können hinter Funktionen versteckt sein, die erste ist meist schon in gen_server:call/2,3 gegen einen gen_server OTP Verhaltensprozess verfügbar.
Ich sehe asynchrones Messaging wie in Erlang als den besseren Ansatz, da bei hohen Latenzen eine Synchronisierung beim Messaging zwischen Computern sehr wahrscheinlich vermieden werden sollte. Man kann dann clevere Wege zur Implementierung der Flusssteuerung zusammenstellen. Nehmen wir an, wir müssen für jede N-Nachricht, die der Produzent gesendet hat, eine Bestätigung vom Kunden anfordern oder eine spezielle Nachricht "ping mich, wenn Sie diese erhalten haben", um die Ping-Zeit zu zählen.
___ tag123actor ___ Programmiermodell, das sich durch ubiquitäre asynchrone Kommunikation auszeichnet.
___ qstntxt ___
Ich habe zwei Methoden zur "Nachrichtenübergabe" bemerkt. Eins habe ich von Erlang gesehen und das andere stammt von Stackless Python. Von dem, was ich hier verstehe, ist der Unterschied
Erlang Style - Nachrichten werden gesendet und in die Mailbox des empfangenden Prozesses eingereiht. Von dort werden sie auf FIFO-Basis entfernt. Sobald der erste Prozess die Nachricht sendet, ist es frei, fortzufahren.
Python-Stil - Verarbeitet eine Warteschlange, die an Prozess B gesendet werden soll. B führt gerade eine andere Aktion durch, so dass A eingefroren wird, bis B zum Empfang bereit ist. Sobald B einen Lesekanal öffnet, sendet A die Daten und dann beide weiter.
Jetzt sehe ich die Vorteile der Erlang-Methode darin, dass Sie keine blockierten Prozesse haben. Wenn B niemals empfangen kann, kann A trotzdem fortfahren. Allerdings habe ich in einigen Programmen festgestellt, dass es für Erlang-Nachrichtenboxen möglich ist, mit Hunderten (oder Tausenden) von Nachrichten voll zu werden, da der Nachrichtenfluss größer ist als der Abfluss.
Jetzt habe ich kein großes Programm in irgendeinem Framework / Sprache geschrieben, also frage ich mich, ob deine Erfahrungen damit sind, und ob es etwas ist, worüber ich mir Sorgen machen sollte.
Ja, ich weiß, das ist abstrakt, aber ich suche auch nach eher abstrakten Antworten.
___ tag123stackless ___ Stackless bezieht sich auf eine Code-Implementierung, die keinen Aufruf-Stack verwendet. Haskell ist ein Beispiel für eine stapellose Sprache
___ tag123pythonackless ___ Stackless Python ist eine experimentelle Implementierung der Python-Sprache; Stackless wurde von Anfang an entwickelt, um die Einschränkungen von cPythons Global Interpreter Lock zu umgehen, indem Tasklets verwendet werden, die Funktionen als Microthreads implementieren.
___ tag123python ___ Python ist eine dynamische und stark typisierte Programmiersprache, die die Usability betont. Zwei ähnliche, aber größtenteils inkompatible Versionen von Python sind weit verbreitet (2 und 3). Wenn Sie eine versionsspezifische Python-Frage haben, sollten Sie die Tags [python-2.7] oder [python-3.x] zusätzlich zum Tag [python] verwenden. Wenn Sie eine Python-Variante wie jython, pypy, iron-python usw. verwenden, kennzeichnen Sie diese bitte entsprechend.
___