Flujo de eventos. ¿Cómo controlar y hacer que el evento sea inactivo? (+ resuelto) - página 3

Nuevo comentario
 

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.

 
sergeev:

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?

¿Han respondido ya Renat y Rosh a esta pregunta?
 
Rosh:

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.

Rosh:

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.

 
Yedelkin:

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.

Y no olvidemos que el EA ha obtenido los eventos de los indicadores que se han ejecutado en muchas herramientas y marcos temporales, unos 80 en total, si no recuerdo mal. Cada indicador consume recursos para los buffers de los indicadores, ahí es donde se entierra el perro.
 
sergeev:

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.

sergeev:

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:

void OnChartEvent(int iview, int id, long lparam, double dparam, string sparam)
{
    if (id==CHARTEVENT_CUSTOM+VM_IDLE)
    {
      ... 
    }
    EventChartCustom(m_chart, VM_IDLE, (long)event_idle, 0, ""); // отправили событие с указанием последнего счетчика
}

Obviamente en este código EventChartCustom no está dentro deOnChartEvent, y estoy muy equivocado :)

sergeev:

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.

 
Yedelkin:

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.

 
Rosh:
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 fácil: tengo un indicador universal con 8 o 15 buffers de indicadores calculados que se ejecutan en 6 instrumentos en un marco temporal. Es decir, sólo hay 6 indicadores. ¿Y, teóricamente, un esquema así puede consumir 2 GB en una semana?
 
Yedelkin:
¿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?
Lee el artículo Reducir el consumo de memoria de los indicadores auxiliares, puede ser útil.
 
Rosh:
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?

1234567
Nuevo comentario