Flujo de eventos. ¿Cómo controlar y hacer que el evento sea inactivo? (+ resuelto) - página 3
![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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:
Del mismo modo, si ya hay un evento ChartEventen la cola de mql5-programa o dicho evento está siendo manejado, entonces el nuevo evento de dicho tipo no se pone en cola".
Hmm. Esto es realmente malo. Teóricamente significa que si, digamos, un indicador y un Asesor Experto utilizan eventos de forma independiente, entonces puede haber saltos en ambos casos.
Entonces no tiene sentido utilizar el evento como una forma fiable de transferir datos.
Lástima.
Tu pregunta "con qué frecuencia aproximada deben enviarse los eventos personalizados 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 debería 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.
Una vez más, amablemente :) Tú has resuelto tu problema, yo estoy tratando de resolver el mío, de un plan diferente. Al leer la discusión, no encontré respuesta a mis preguntas. Todavía no has respondido a mi pregunta principal (sobre el uso de la memoria) (si es que decides hacerlo).
Déjeme explicarle. No tengo la tarea "para actualizar alguna función, pero más rápido que MQL sugiere el uso de un temporizador". Más aún con la forma tan inteligente que se sugirió al final. Los eventos personalizados de varios gráficos con frecuencia variable bombardean un gráfico separado que contiene el Asesor Experto y la función del manejador de eventos. En consecuencia, el resultado de su tarea estrechamente enfocada(EventChartCustom dentro de OnChartEvent) no encaja en absoluto con mi esquema de trabajo con eventos personalizados.
Yedelkin:
Para aclarar. No tengo la tarea de "hacer que alguna función se actualice más rápido de lo que sugiere MQL por temporizador". Y menos de una forma tan inteligente, como se sugiere al final. Los eventos personalizados de varios gráficos con frecuencia variable bombardean un gráfico separado que contiene el Asesor Experto y la función del manejador de eventos. En consecuencia, el resultado de su tarea estrechamente enfocada(EventChartCustom dentro de OnChartEvent) no encaja en absoluto con mi esquema de trabajo con eventos personalizados.
no es enrevesado, es sencillo. Si no eres capaz de entenderlo, no es mi problema. eso es una
No está dentro de OnChartEvent, está disperso por todo el código. Te estás inventando tus propias limitaciones en su funcionamiento. Son dos.
Del mismo modo, si ya hay un evento ChartEvent en la cola de mql5-programa o se está gestionando un evento de este tipo, un nuevo evento de este tipo no se colocará en la cola.
Se trata de un fallo o de un error de documentación o de la falta de condiciones.
Los eventos se ponen en cola con éxito y no se descarta ningún evento. De lo contrario, mi tema no habría aparecido.
Estoy tratando de resolver mi otro problema
¿qué efecto tiene el desbordamiento de la cola de eventos en el tamaño de la RAM? Si la cola de eventos resulta estar desbordada, ¿a dónde van los eventos que desbordaron la cola?
Si se descarta un evento, simplemente no se pone en cola. La memoria no crece.
¡Uf! Eso es lo principal que quería entender. Y dado que TheXpert dijo que sólo se gastan unos pocos MB en la cola en sí, es probable que la fuga de memoria esté en otra parte... Sigamos con esa afirmación hasta que se demuestre lo contrario.
Si se produce este tipo de problema, las cosas están muy mal. Creo que la cola de eventos desbordada es el último lugar donde buscar problemas de memoria.
Sí, intento buscar en todos los sitios que puedo.
Pero nótese que de los tres expertos descalificados, al menos dos trabajaban con un flujo de eventos personalizado (el autor del tercero no responde a la solicitud). Lizar (trabajando con eventos personalizados) tiene un alto uso de memoria, también. Y tol64 tiene un consumo de memoria extremadamente bajo porque los eventos de usuario se utilizan con menos frecuencia que una vez por minuto, si lo he entendido bien. Así pues, resulta que habrá que dudar de la eficacia de aplicar el concepto de eventos personalizados a discreción, hasta que se obtenga una respuesta exhaustiva.
Pero nótese que de los tres EAs descalificados, al menos dos trabajaban con un flujo de eventos personalizados (el autor del tercero no responde a la solicitud). Lizar (que trabaja con eventos personalizados) también tiene un alto consumo de memoria. Y tol64 tiene un consumo de memoria extremadamente bajo porque los eventos de usuario se utilizan con menos frecuencia que una vez por minuto, si lo he entendido bien. Así pues, resulta que habrá que dudar de la eficacia de implementar el concepto de eventos personalizados a discreción, hasta que se obtenga una respuesta exhaustiva.
no es complicado, es sencillo. Si no puedes entenderlo, no es mi problema.
Según entendí, escribí que es complicado. Si no, no lo habría tocado.
No está dentro de OnChartEvent, está en todo el código. Te estás inventando tus propias y estrechas limitaciones sobre cómo funciona. Son dos.
Sí, sí, EventChartCustom no está dentro de OnChartEvent, sino fuera. Ahora mira tu propio código:
Obviamente en este código EventChartCustom no está dentro deOnChartEvent, y estoy muy equivocado :)
está mal o es un bug o un error de documentación o una condición subestimada.
Todos los eventos que se han realizado con éxito permanecen en la cola y no se descarta ningún evento. De lo contrario, mi tema no habría aparecido.
Hay al menos una versión más: en su caso particular, la cola simplemente no se desborda (debido a la eficiencia del código), por lo que no hay hechos de descarte de eventos.
Hay al menos otra versión: en su caso particular, la cola simplemente no se desborda (debido a la eficiencia del código), por lo que no hay evidencia de que se descarten eventos.
Este es mi caso particular en el que empecé a demostrar que no descartaba eventos idénticos
https://www.mql5.com/ru/forum/5091#comment_112780
Allí escribí por qué se produce el desbordamiento.
Sí, sí, EventChartCustom no está dentro de OnChartEvent, sino fuera. Ahora mira tu propio código:
Llega a la raíz. He mostrado una demostración del problema y su solución. Esta llamada a EventChart podría estar en cualquier parte del código.
Y no olvidemos el hecho de que el Asesor Experto recibía los eventos de los indicadores que se ejecutaban en muchas herramientas y marcos temporales, unos 80 en total, si no recuerdo mal. Cada indicador consume recursos para los buffers de los indicadores, y ahí está el perro.
¿Te refieres a los japoneses? Bueno, en mi caso es más sencillo: un indicador universal con 8 o 15 buffers de indicadores de cálculo, que se ejecutan en 6 instrumentos en un marco temporal. Es decir, sólo hay 6 indicadores. En teoría, un esquema de este tipo puede consumir 2 GB en una semana?
Lea el artículo Reducir el consumo de memoria de los indicadores auxiliares, puede ser útil.
Gracias, ya tengo todo optimizado allí :) Incluso con este artículo en mente, por lo que recuerdo. Tendré que esperar al siguiente grado de iluminación :)
¿Es posible determinar el Asesor Experto y el indicador por separado, si trabajan juntos a través de eventos personalizados?