La suscripción a OnBookEvent a veces se cae - ¿existe? - 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
"basta con que un experto deje de recibir el evento para que todos los demás expertos dejen de recibirlo también"...
Es sólo una conjetura para saber si vale la pena o no, en la analogía de seguir diciendo que "basta con que un EA se dé de baja de la recepción de un evento, para que todos los demás EA dejen de recibirlo también"? No creo que pueda existir tal cosa, sería (o es) un error.
Por un lado, es fácil de comprobar. Lo haría yo mismo, pero sólo tengo una cuenta de FORTS y está cerrada el fin de semana.
Pero si es así, la situación resulta divertida. Cuando ha activado el Asesor Experto y el indicador, las suscripciones se han activado. Cuando desactiva el Asesor Experto o el indicador, ya ha escrito que las suscripciones se han colapsado. Esto sugiere que la radiodifusión funciona en la dirección opuesta. Ahora imagine que algo ha cambiado (por ejemplo, el historial ha cambiado y el indicador se ha recalculado). Pero sabemos que OnInit y OnDeinit pueden ser llamados al azar. A veces es correcto, y otras veces es viceversa. ¿Qué ocurrirá si el gráfico llama primero a la nueva versión del indicador y luego desinstala la antigua? El abono caerá. Eso es lo que sería "caerse tranquilamente". Te recomendaría que pusieras impresoras en OnInit y OnDeinit para comprobar la cola y el mensaje en caso de que dejen de llegar citas en la ventana de apuestas. Tal vez el problema se aclare.
En primer lugar, es fácil de comprobar. Lo haría yo mismo, pero sólo tengo una cuenta en FORTS y está cerrada el fin de semana.
No necesitaCHARTEVENT_OBJECT_CREATE para comprobar la puntuación en absoluto.
Es una obviedad.
No entiendo. Siempre puedes poner un contador de enlaces
No entiendo. Siempre puedes poner un contador de enlaces
No hay contador. Y si lo hubiera, se indicaría explícitamente en la documentación su existencia y la admisibilidad de la llamada al par Add\Release, de lo contrario el contador se rompería y se perdería el sentido de su existencia
Y si dices que necesitas un contador de referencias... entonces se podría ir más allá y abolir la radiodifusión por completo
No hay contador. Y si lo hubiera, se indicaría claramente en la documentación que existe y que sólo se permite la llamada emparejada Add/Release - de lo contrario se perderá el contador y el sentido de su existencia
y ahora mismo la función de liberación no tiene sentido porque la lógica de que cualquiera puede darse de baja de su evento es un sinsentido.
Hay una simple sugerencia de no utilizar la funciónMarketBookRelease.
En teoría, esto desperdiciaría parte de los recursos del terminal y del servidor.
Pero en la práctica... ¿Habrá consecuencias reales de esto?
Pues ahora no tiene sentido la función de liberación. porque la lógica de que cualquiera puede darse de baja de su evento es una lógica sin sentido
Es inútil explicarlo para los erizos, así que escribiré para los demás ;-).
La noción de difusión de eventos es una cosa, pero los principios de la llamada a pares de las funciones de suscripción y desuscripción a un evento es otra. Se trata de técnicas semánticamente independientes que no tienen por qué, e idealmente no deberían, afectarse mutuamente. Permitir que el evento sea transmitido (esto se hizo probablemente por razones de eficiencia, pero es muy controvertido y puede causar el problema actual si se implementa incorrectamente). Esto significa que basta con que uno se suscriba, para que todos reciban el evento. Pero a la inversa -uno tiene que darse de baja y todos se joden- ya es una especie de narrowcasting.
Sobre el contador de abonados en la documentación no se menciona, aunque es muy importante (y la frase sobre la difusión no es una explicación por la razón anterior). La difusión debería durar, idealmente, hasta que el número de suscriptores disminuya a 0. De lo contrario, es obvio que los programas MQL (incluidos los de diferentes desarrolladores) tendrían que comunicarse entre sí de alguna manera, para no perjudicar su trabajo, pero esto no tiene sentido. No conozco un solo ejemplo de software (en sentido amplio, no limitado a MT, Windows, etc.) en el que la suscripción se haya implementado de esta manera.
Hay un pasaje sobre MarketBookRelease:
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
Es, de nuevo, ambiguo. Podría interpretarse como un control del número de suscripciones. Pero el software no permite interpretaciones privadas.
En resumen, IMHO, la implementación es un rastrillo (la verificación y la sobresuscripción se requiere a nivel de MQL), la documentación es turbia. La afirmación de que un código malicioso o directamente malo puede acabar con las suscripciones de otros incluso con un contador no es realmente relevante. Todos estos scripts podrían hacer daño en un montón de otros lugares en el terminal (por ejemplo, borrar los objetos de otras personas, matar paradas en las posiciones de otras personas, etc., lo que ha sucedido un millón de veces antes). No tiene sentido hablar de tales manifestaciones de cerdito - no pueden ser prevenidas por nada, excepto por la disciplina del usuario, la revisión del código de otros usuarios (si lo hay) o la comprobación en una demo. El problema ahora es que el código bien escrito no puede ejecutarse correctamente.
Si hiciéramos este mecanismo correctamente, por supuesto - el patrón editor/suscriptor no ha sido abolido. Desde luego, no afectaría a la eficiencia.