Flujo de eventos. ¿Cómo controlar y hacer que el evento sea inactivo? (+ resuelto) - página 2
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Yedelkin:
En consecuencia, aún no está claro con qué frecuencia deben enviarse los eventos de usuario para que no desborden la cola de eventos del terminal...
No encuentro respuesta a la pregunta: ¿cómo afecta el desbordamiento de la cola de eventos al tamaño de la RAM? Si la cola de eventos se llena, ¿a dónde van los eventos que desbordan la cola? ¿Se libera una parte de la memoria RAM, reservada para aquellos acontecimientos que quedaron "fuera de la historia"?
Quizá mis preguntas no sean terminológicamente correctas, pero (espero) captan la esencia del problema.
La cola es dinámica y crece por necesidad.
Pero al llegar a un determinado límite, se descartan los nuevos eventos, ya que está claro que no tiene sentido seguir cargando la cola.
Se nota enseguida que no has leído mis posts.
¿Por qué no lo has "leído"? Tú has resuelto tu problema, yo estoy intentando resolver el mío, de otro tipo. Cuando leí la discusión, no encontré respuesta a mis preguntas.
No has respondido a mi pregunta principal. :/ Eso es exactamente el "ver de un vistazo" :)
La cola es dinámica y crece por necesidad.
Pero a partir de cierto límite, se descartan los nuevos eventos, porque está claro que no tiene sentido seguir cargando la cola.
Bien, la cola es "dinámica". Aumenta hasta un límite "determinado". Pero por qué nadie puede dar una respuesta a una pregunta aparentemente sencilla: ¿cómo afecta el desbordamiento de la cola de eventos al tamaño de la memoria?
Preguntas complementarias: ¿Cuánta RAM se necesita para "mantener" una cola de eventos desbordada? Si "al llegar a un determinado límite, se descartan los nuevos eventos", ¿se libera la RAM previamente asignada para estos eventos descartados?
Objetivo de las preguntas: entender cómo el flujo de eventos del usuario puede aumentar (aumenta) la cantidad de RAM consumida por el terminal.
Si la cola de eventos está llena, ¿a dónde van los eventos que desbordan la cola? ¿Se libera una parte de la memoria RAM reservada para los eventos que están "fuera de la historia"?
Quizá mis preguntas no sean terminológicamente correctas, pero (espero) transmiten la esencia del problema.
La sección dice Ejecución del programa que los nuevos eventos se descartan cuando la cola se desborda:
El terminal cliente envía los eventos que se producen a los gráficos abiertos correspondientes. Los eventos también pueden ser generados por los gráficos (eventos de gráficos) o los programas mql5 (eventos personalizados). La generación de eventos de creación y eliminación de objetos gráficos en un gráfico puede activarse o desactivarse estableciendo las propiedades CHART_EVENT_OBJECT_CREATE y CHART_EVENT_OBJECT_DELETE de un gráfico. Cada programa mql5 y cada gráfico tienen su propia cola de eventos, donde se almacenan todos los nuevos eventos.
El programa recibe eventos sólo del gráfico en el que se está ejecutando. Todos los eventos se procesan uno por uno en el orden de recepción. Si ya hay un evento NewTick en la cola o si este evento está en estado de procesamiento, no se coloca un nuevo evento NewTick en la cola del programa mql5. Del mismo modo, si la cola del programa mql5 ya contiene el evento ChartEvent o el evento está siendo procesado, un nuevo evento de este tipo no se coloca en la cola.
Las colas de eventos tienen un tamaño limitado, pero suficiente, por lo que el desbordamiento de la cola para un programa correctamente escrito es poco probable. Cuando se produce el desbordamiento de la cola, los nuevos eventos se descartan sin ser puestos en cola.
Se desaconseja encarecidamente el uso de bucles infinitos para procesar eventos. La única excepción a esta regla son los scripts que manejan un solo evento de Inicio.
Las bibliotecas no manejan ningún evento.
¿Por qué no lo has "leído"? Tú has resuelto tu problema, yo estoy intentando resolver el mío, de otro tipo. Cuando leí la discusión, no encontré respuesta a mis preguntas.
No has respondido a mi pregunta principal. :/ Definitivamente pude "ver de inmediato" :)
Tu pregunta "¿cuál es la frecuencia aproximada con la que deben enviarse los eventos de usuario, para que no desborden la cola?".
Mi respuesta en la primera página es "con la frecuencia de las llamadas OnChartEvent".
Es decir, un evento es un OnChartEvent. No debe haber más de dos eventos entre ellos.
Esas son todas las matemáticas.
Una vez más, lea la primera página. Mostré cómo evitar la acumulación de eventos de usuario cuando se procesa un evento de terminal en lugar de un evento de usuario. Es tan sencillo como eso.
Objetivo de las preguntas: entender cómo un hilo de eventos de usuario puede aumentar (incrementar) el tamaño de la RAM consumida por el terminal.
¿Por qué? Pues sí, así es. El precio de la pregunta es de unos pocos megabytes.
Ese no es el problema, o no es realmente el problema.
La sección dice Ejecución del Programa, que..:
1. La sección del Manual ha sufrido importantes cambios.
1.1 Por ejemplo, antes era:"El terminal cliente pone todos los eventos que se producen en una cola común. Así, los eventos se procesan uno tras otro en orden de llegada. La excepción es el evento NewTick. Si ya existe un evento de este tipo en la cola o si este evento está siendo procesado, no se coloca un nuevo evento NewTick en la cola".
Ahora:"El programa recibe eventos sólo del gráfico en el que se está ejecutando. Todos los eventos se procesan uno tras otro en el orden en que se reciben. Si ya hay un evento NewTick en la cola o este evento está en estado de procesamiento, no se coloca un nuevo evento NewTick en la cola del programa mql5. Del mismo modo, si la cola del programa mql5 ya contiene un evento ChartEvent o se está procesando un evento de este tipo, no se pondrá en cola un nuevo evento de este tipo.
Como dice el refrán, "vea la diferencia". Al menos debería estar advertido. :/ Este cambio modifica fundamentalmente la forma de trabajar con los eventos personalizados.
1.2. Siguiente. El principio de descarte de eventos se pone al revés. Antes era: "La cola de eventos tiene un tamaño limitado. Cuando la cola se llena, los eventos más antiguos se eliminan sin procesar para dejar espacio a los eventos recién llegados".
Ahora: "Cuando la cola está llena, los nuevos eventos se descartan sin ser puestos en cola". Como se dice, gracias: perdemos los eventos de usuario más relevantes.
2. La sección citada del Manual no responde a mis preguntas básicas: ¿Cómo afecta el desbordamiento de la cola de eventos al tamaño de la memoria RAM? ¿Cuánta memoria RAM se necesita para "mantener" una cola de eventos desbordada? Si "al llegar a un determinado límite, se descartan nuevos eventos", ¿se libera la memoria RAM previamente asignada para esos eventos descartados?
TheXpert:
Objetivo de las preguntas: entender cómo un hilo de eventos de usuario puede aumentar (incrementar) el tamaño de la RAM consumida por el terminal.
¿Por qué? Pues sí, así es. La pregunta vale varios megabytes.
2. La sección citada del Manual no responde a mis principales preguntas: ¿Cómo afecta el desbordamiento de la cola de eventos al tamaño de la memoria RAM? ¿Cuánta memoria RAM se necesita para "mantener" una cola de eventos desbordada? Si "al llegar a un determinado límite, se descartan nuevos eventos", ¿se libera la memoria RAM previamente asignada para esos eventos descartados?
Si surgen estos problemas, las cosas están muy mal. Creo que una cola de eventos desbordada es el último lugar donde buscar problemas de memoria.
Si se descarta un evento, es que no se pone en la cola. La memoria no crece.