Flux d'événements. Comment contrôler et rendre l'événement inactif ? (+ résolu) - page 2
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Yedelkin:
En conséquence, la fréquence à laquelle les événements utilisateur doivent être envoyés pour ne pas déborder de la file d'attente des événements du terminal n'est toujours pas claire...
Je ne trouve pas de réponse à la question suivante : comment le dépassement de la file d'attente des événements affecte-t-il la taille de la RAM ? Si la file d'attente des événements est pleine, où vont les événements qui ont débordé de la file d'attente ? Une partie de la mémoire vive, réservée aux événements qui se trouvent être "hors de l'histoire", est-elle libérée ?
Mes questions ne sont peut-être pas terminologiquement correctes, mais (j'espère) elles saisissent l'essence du problème.
La file d'attente est dynamique et s'agrandit par nécessité.
Mais à partir d'une certaine limite, les nouveaux événements sont écartés car il est clair qu'il est inutile de charger davantage la file d'attente.
Je peux dire tout de suite que vous n'avez pas lu mes messages.
Pourquoi ne l'avez-vous pas "lu" ? Vous avez résolu votre problème, j'essaie de résoudre le mien, d'un autre genre. En lisant la discussion, je n'ai pas trouvé de réponse à mes questions.
Vous n'avez pas répondu à ma question principale. :/ C'est exactement le "coup d'œil" :)
La file d'attente est dynamique et s'agrandit par nécessité.
Mais à partir d'une certaine limite, les nouveaux événements sont écartés, car il est clair qu'il est inutile de charger davantage la file d'attente.
OK, la file d'attente est "dynamique". Augmente jusqu'à une "certaine" limite. Mais pourquoi personne ne peut donner une réponse à une question apparemment simple : comment le dépassement de la file d'attente des événements affecte-t-il la taille de la mémoire?
Questions complémentaires : Quelle quantité de RAM est nécessaire pour "maintenir" une file d'attente d'événements débordante ? Si "à une certaine limite, les nouveaux événements sont rejetés", la RAM précédemment allouée pour ces événements rejetés est-elle libérée ?
But des questions : comprendre comment le flux d'événements de l'utilisateur peut augmenter (augmente) la quantité de RAM consommée par le terminal.
Si la file d'attente des événements est pleine, où vont les événements qui ont débordé de la file d'attente ? Est-ce qu'une partie de la RAM réservée aux événements "hors histoire" est libérée ?
Mes questions ne sont peut-être pas terminologiquement correctes, mais (j'espère) elles transmettent l'essence du problème.
La section " Exécution du programme" indique que les nouveaux événements sont rejetés lorsque la file d'attente déborde:
Le terminal client envoie les événements qui se produisent aux graphes ouverts appropriés. Les événements peuvent également être générés par des graphiques (événements graphiques) ou des programmes mql5 (événements personnalisés). La génération d'événements de création et de suppression d'objets graphiques sur un graphique peut être activée ou désactivée en définissant les propriétés CHART_EVENT_OBJECT_CREATE et CHART_EVENT_OBJECT_DELETE d'un graphique. Chaque programme mql5 et chaque graphique a sa propre file d'attente d'événements, où tous les nouveaux événements sont stockés.
Le programme ne reçoit des événements que de la carte sur laquelle il est exécuté. Tous les événements sont traités un par un dans l'ordre de leur réception. S'il y a déjà un événement NewTick dans la file d'attente ou si cet événement est en cours de traitement, un nouvel événement NewTick n'est pas placé dans la file d'attente du programme mql5. De même, si la file d'attente du programme mql5 contient déjà l'événement ChartEvent ou si l'événement est en cours de traitement, un nouvel événement de ce type n'est pas placé dans la file d'attente.
Les files d'attente d'événements ont une taille limitée, mais suffisante, de sorte que le débordement de la file d'attente pour un programme correctement écrit est peu probable. Lorsque la file d'attente déborde, les nouveaux événements sont rejetés sans être mis en file d'attente.
Il est fortement déconseillé d'utiliser des boucles infinies pour traiter les événements. La seule exception à cette règle concerne les scripts qui gèrent un seul événement de démarrage.
Lesbibliothèques ne gèrent pas d'événements.
Pourquoi ne l'avez-vous pas "lu" ? Vous avez résolu votre problème, j'essaie de résoudre le mien, d'un autre genre. En lisant la discussion, je n'ai pas trouvé de réponse à mes questions.
Vous n'avez pas répondu à ma question principale. :/ Je pourrais certainement "voir tout de suite" :)
Votre question "quelle est la fréquence approximative à laquelle les événements utilisateur doivent être envoyés, afin qu'ils ne débordent pas de la file d'attente".
Ma réponse sur la première page est "avec la fréquence des appels OnChartEvent".
C'est-à-dire qu'un événement est un OnChartEvent et qu'il ne doit pas y avoir plus de deux événements entre les deux.
C'est tout ce qu'il faut savoir.
Encore une fois, lisez la première page. J'ai montré comment éviter l'accumulation d'événements utilisateur lorsque l'événement terminal est traité au lieu de l'événement utilisateur. C'est aussi simple que cela.
But des questions : comprendre comment un fil d'événements utilisateur peut augmenter (accroître) la taille de la RAM consommée par le terminal.
Pourquoi ? Eh bien, oui, c'est le cas. Le prix de la question est de quelques mégaoctets.
Ce n'est pas le problème, ou pas vraiment le problème.
La section parle d'exécution de programme, ce qui... :
1. la section Manuel a subi des changements importants.
1.1 Par exemple, on disait auparavant :"Le terminal client place tous les événements qui se produisent dans une file d'attente commune. Les événements sont donc traités les uns après les autres dans l'ordre d'arrivée. L'exception est l' événement NewTick. S'il existe déjà un tel événement dans la file d'attente ou si cet événement est en cours de traitement, un nouvel événement NewTick n'est pas placé dans la file d'attente".
Maintenant :"Le programme ne reçoit des événements que de la carte sur laquelle il fonctionne. Tous les événements sont traités les uns après les autres dans l'ordre où ils sont reçus. S'il y a déjà un événement NewTick dans la file d'attente ou si cet événement est en cours de traitement, un nouvel événement NewTick n'est pas placé dans la file d'attente du programme mql5. De même, si la file d'attente de mql5-program contient déjà un événement ChartEvent ou si un tel événement est en cours de traitement, un nouvel événement de ce type ne sera pas mis en file d'attente.
Comme le dit le dicton, "voyez la différence". Vous devriez au moins être prévenu. :/ Cette modification change fondamentalement la façon dont nous travaillons avec les événements personnalisés.
1.2. Suivant. Le principe de la mise au rebut des événements est renversé. Avant, c'était "La file d'attente des événements a une taille limitée. Lorsque la file d'attente est pleine, les anciens événements sont supprimés sans être traités pour faire de la place aux nouveaux événements entrants".
Maintenant : "Lorsque la file d'attente est pleine, les nouveaux événements sont rejetés sans être mis en file d'attente". Comme ils disent, merci : nous perdons les événements les plus pertinents pour l'utilisateur.
2. La section citée du manuel ne répond pas à mes questions fondamentales : Comment le dépassement de la file d'attente des événements affecte-t-il la taille de la RAM ? Combien de RAM est nécessaire pour "maintenir" une file d'attente d'événements débordante ? Si "à une certaine limite, les nouveaux événements sont rejetés", la RAM précédemment allouée pour ces événements rejetés est-elle libérée ?
TheXpert:
But des questions : comprendre comment un fil d'événements utilisateur peut augmenter (accroître) la taille de la RAM consommée par le terminal.
Pourquoi ? Eh bien, oui, c'est le cas. La question vaut plusieurs mégaoctets.
2. La section citée dans le manuel ne répond pas à mes principales questions : Comment le dépassement de la file d'attente des événements affecte-t-il la taille de la RAM ? Combien de RAM est nécessaire pour "maintenir" une file d'attente d'événements débordante ? Si "à une certaine limite, les nouveaux événements sont rejetés", la RAM précédemment allouée pour ces événements rejetés est-elle libérée ?
Si de tels problèmes surviennent, alors les choses vont très mal. Je pense qu'une file d'attente d'événements débordante est le dernier endroit où chercher des problèmes de mémoire.
Si un événement est écarté, c'est qu'il n'est pas placé dans la file d'attente. La mémoire ne se développe pas.