Event-Stream. Wie kann man das Ereignis kontrollieren und in den Leerlauf versetzen? (+ gelöst) - Seite 2
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Yedelkin:
Dementsprechend ist es immer noch unklar, wie oft Benutzerereignisse gesendet werden sollten, damit sie die Warteschlange des Terminals nicht überfüllen...
Ich kann keine Antwort auf die Frage finden: Wie wirkt sich ein Überlauf der Ereigniswarteschlange auf die RAM-Größe aus? Wenn die Ereigniswarteschlange voll ist, wohin gehen dann die Ereignisse, die die Warteschlange überfüllt haben? Wird ein Teil des Arbeitsspeichers, der für die Ereignisse reserviert ist, die nicht mehr in der Geschichte vorkommen, wieder freigegeben?
Vielleicht sind meine Fragen terminologisch nicht korrekt, aber sie treffen (so hoffe ich) den Kern des Problems.
Die Warteschlange ist dynamisch und wächst zwangsläufig.
Ab einer bestimmten Grenze werden jedoch neue Ereignisse verworfen, da es offensichtlich keinen Sinn macht, die Warteschlange weiter zu belasten.
Ich erkenne sofort, dass Sie meine Beiträge nicht gelesen haben.
Warum haben Sie es nicht "gelesen"? Sie haben Ihr Problem gelöst, ich versuche, meins zu lösen, allerdings auf eine andere Art. Als ich die Diskussion gelesen habe, habe ich keine Antwort auf meine Fragen gefunden.
Sie haben meine Hauptfrage nicht beantwortet. :/ Das ist genau das "auf einen Blick sehen" :)
Die Warteschlange ist dynamisch und wächst zwangsläufig.
Ab einer bestimmten Grenze werden jedoch neue Ereignisse verworfen, da es offensichtlich keinen Sinn macht, die Warteschlange weiter zu füllen.
OK, die Warteschlange ist "dynamisch". Erhöht sich bis zu einer "bestimmten" Grenze. Aber warum kann niemand eine Antwort auf eine scheinbar einfache Frage geben: Wie wirkt sich ein Überlauf der Ereigniswarteschlange auf die Speichergröße aus?
Folgefragen: Wie viel Arbeitsspeicher wird benötigt, um eine überlaufende Ereigniswarteschlange "aufrechtzuerhalten"? Wenn "ab einer bestimmten Grenze neue Ereignisse verworfen werden", wird dann der zuvor für diese verworfenen Ereignisse zugewiesene Arbeitsspeicher wieder freigegeben?
Zweck der Fragen: Verstehen, wie der Benutzer-Ereignisstrom den vom Terminal verbrauchten Arbeitsspeicher erhöhen kann (erhöht).
Wenn die Ereigniswarteschlange voll ist, wohin gehen dann die Ereignisse, die die Warteschlange überfüllt haben? Wird ein Teil des Arbeitsspeichers, der für Ereignisse reserviert ist, die "nicht mehr in der Geschichte" vorkommen, freigegeben?
Vielleicht sind meine Fragen terminologisch nicht korrekt, aber sie bringen (so hoffe ich) den Kern des Problems auf den Punkt.
Im Abschnitt " Programmausführung" heißt es, dass neue Ereignisse verworfen werden, wenn die Warteschlange überläuft:
Das Client-Terminal sendet die auftretenden Ereignisse an die entsprechenden offenen Graphen. Ereignisse können auch von Diagrammen (Diagrammereignisse) oder mql5-Programmen (benutzerdefinierte Ereignisse) erzeugt werden. Die Erzeugung von Ereignissen zum Erstellen und Löschen von grafischen Objekten in einem Diagramm kann durch die Einstellung der Eigenschaften CHART_EVENT_OBJECT_CREATE und CHART_EVENT_OBJECT_DELETE eines Diagramms aktiviert oder deaktiviert werden. Jedes mql5-Programm und jedes Diagramm hat seine eigene Warteschlange für Ereignisse, in der alle neuen Ereignisse gespeichert werden.
Das Programm empfängt nur Ereignisse von der Karte, auf der es läuft. Alle Ereignisse werden nacheinander in der Reihenfolge ihres Eingangs bearbeitet. Befindet sich bereits ein Ereignis NewTick in der Warteschlange oder ist dieses Ereignis im Verarbeitungsstatus, wird ein neues Ereignis NewTick nicht in die Warteschlange des mql5-Programms gestellt. Wenn die Warteschlange des mql5-Programms bereits ein ChartEvent-Ereignis enthält oder das Ereignis gerade verarbeitet wird, wird ein neues Ereignis dieses Typs nicht in die Warteschlange gestellt.
Ereigniswarteschlangen haben eine begrenzte, aber ausreichende Größe, so dass ein Überlauf der Warteschlange bei einem korrekt geschriebenen Programm unwahrscheinlich ist. Wenn die Warteschlange überläuft, werden neue Ereignisse verworfen, ohne in die Warteschlange aufgenommen zu werden.
Von der Verwendung von Endlosschleifen zur Verarbeitung von Ereignissen wird dringend abgeraten. Die einzige Ausnahme von dieser Regel sind Skripte, die ein einzelnes Startereignis behandeln.
DieBibliotheken behandeln keine Ereignisse.
Warum haben Sie es nicht "gelesen"? Sie haben Ihr Problem gelöst, ich versuche, meins zu lösen, allerdings auf eine andere Art. Als ich die Diskussion gelesen habe, habe ich keine Antwort auf meine Fragen gefunden.
Sie haben meine Hauptfrage nicht beantwortet. :/ Ich konnte definitiv "sofort sehen" :)
Ihre Frage "Mit welcher ungefähren Häufigkeit sollten Benutzerereignisse gesendet werden, damit die Warteschlange nicht überläuft".
Meine Antwort auf der ersten Seite lautet "mit der Häufigkeit der OnChartEvent-Aufrufe".
Das heißt, ein Ereignis ist ein OnChartEvent. Es sollten nicht mehr als zwei Ereignisse dazwischen liegen.
Das war's mit der Mathematik.
Noch einmal: Lesen Sie die erste Seite. Ich habe gezeigt, wie man die Anhäufung von Benutzerereignissen vermeiden kann, wenn ein Terminalereignis anstelle eines Benutzerereignisses verarbeitet wird. So einfach ist das.
Zweck der Fragen: zu verstehen, wie ein Thread von Benutzerereignissen die Größe des vom Terminal verbrauchten Arbeitsspeichers erhöhen (vergrößern) kann.
Und warum? Nun, ja, das stimmt. Der Preis für diese Frage beträgt einige Megabyte.
Das ist nicht das Problem, oder nicht wirklich das Problem.
In dem Abschnitt heißt es Programmdurchführung, was...:
1. Der Abschnitt "Handbuch" wurde erheblich geändert.
1.1 Früher hieß es zum Beispiel:"Das Client-Terminal stellt alle auftretenden Ereignisse in eine gemeinsame Warteschlange. Die Ereignisse werden also nacheinander in der Reihenfolge ihres Eintreffens verarbeitet. Die Ausnahme ist das Ereignis NewTick. Befindet sich bereits ein solches Ereignis in der Warteschlange oder wird dieses Ereignis gerade verarbeitet, wird kein neues NewTick-Ereignis in die Warteschlange gestellt".
Jetzt:"Das Programm empfängt nur Ereignisse von der Karte, auf der es läuft. Alle Ereignisse werden nacheinander in der Reihenfolge ihres Eingangs bearbeitet. Wenn sich bereits ein Ereignis NewTick in der Warteschlange befindet oder dieses Ereignis in der Verarbeitung ist, wird ein neues Ereignis NewTick nicht in die Warteschlange des mql5-Programms gestellt. Befindet sich bereits ein Ereignis ChartEvent in der Warteschlange von mql5-program oder wird ein solches Ereignis gerade verarbeitet, wird ein neues Ereignis dieses Typs nicht in die Warteschlange gestellt.
Wie man so schön sagt: "Sehen Sie den Unterschied". Sie sollten zumindest gewarnt werden. Diese Änderung ändert die Art und Weise, wie wir mit benutzerdefinierten Ereignissen arbeiten, grundlegend.
1.2. weiter. Das Prinzip des Verwerfens von Ereignissen wird auf den Kopf gestellt. Früher hieß es: "Die Ereigniswarteschlange hat eine begrenzte Größe. Wenn die Warteschlange voll ist, werden alte Ereignisse gelöscht, ohne dass sie verarbeitet werden , um Platz für neu eingehende Ereignisse zu schaffen".
Jetzt: "Wenn die Warteschlange voll ist, werden neue Ereignisse verworfen, ohne in die Warteschlange aufgenommen zu werden". Wie man so schön sagt: Wir verlieren die wichtigsten Benutzerereignisse.
2. Der zitierte Abschnitt des Handbuchs gibt keine Antwort auf meine grundlegenden Fragen: Wie wirkt sich ein Überlauf der Ereigniswarteschlange auf die RAM-Größe aus? Wie viel Arbeitsspeicher wird benötigt, um eine überlaufende Ereigniswarteschlange zu "unterhalten"? Wenn "ab einer bestimmten Grenze neue Ereignisse verworfen werden", wird dann der Arbeitsspeicher, der zuvor für die verworfenen Ereignisse reserviert war, wieder freigegeben?
TheXpert:
Zweck der Fragen: zu verstehen, wie ein Strom von Benutzerereignissen die Größe des vom Terminal verbrauchten Arbeitsspeichers erhöhen (vergrößern) kann.
Und warum? Nun, ja, das stimmt. Die Frage ist mehrere Megabyte groß.
2. Der zitierte Abschnitt im Handbuch gibt keine Antwort auf meine wichtigsten Fragen: Wie wirkt sich ein Überlauf der Ereigniswarteschlange auf die RAM-Größe aus? Wie viel Arbeitsspeicher wird benötigt, um eine überlaufende Ereigniswarteschlange zu "unterhalten"? Wenn "ab einer bestimmten Grenze neue Ereignisse verworfen werden", wird dann der Arbeitsspeicher, der zuvor für die verworfenen Ereignisse reserviert war, wieder freigegeben?
Wenn solche Probleme auftauchen, ist es sehr schlimm. Ich denke, eine überlaufende Ereigniswarteschlange ist der letzte Ort, an dem man nach Speicherproblemen suchen sollte.
Wenn ein Ereignis verworfen wird, wird es einfach nicht in die Warteschlange gestellt. Der Speicher wächst nicht.