Programación asíncrona y multihilo en MQL - página 8
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
Parece que la diferencia especial entre la asincronía y el multihilo viene del mismo ámbito que la cuestión de la diferencia entre punteros y referencias que aqueja a algunas personas.
La asincronía se implementa a través de un hilo separado y no es tan importante si este proceso es proporcionado por el procesador o cualquier otro dispositivo. La creación de un proceso implica su asincronía porque existe en paralelo.
La asincronía se implementa en el mismo hilo de ejecución del programa, a través de EventLoop, pero cómo se implementa EventLoop es prerrogativa de los desarrolladores, cómo implementarlo.
Los mismos manejadores estándar en mql, por ejemplo OnTimer funciona en su propio bucle, y este es una especie de EventLoop,
Si quieres crear un manejador separado para los métodos asíncronos, todas las tareas se ejecutarán perfectamente en un bucle asíncrono.
La asincronía se implementa en el mismo hilo de ejecución del programa, a través de EventLoop, pero cómo se implementa EventLoop, es prerrogativa de los desarrolladores, cómo implementarlo.
Los mismos manejadores estándar en mql, por ejemplo OnTimer funciona en su propio bucle, y este es una especie de EventLoop,
Si quieres crear un manejador separado para los métodos asíncronos, todas las tareas se ejecutarán perfectamente en un bucle asíncrono.
Disculpe, ¿dónde se implementa la asincronía a través de EventLoop?
Ahora puedes hacer algo como EventLoop por ti mismo, los desarrolladores de terminales no son necesarios aquí en absoluto.
Disculpe, ¿dónde se implementa la asincronía a través de EventLoop?
Ahora puedes hacer algo como EventLoop tú mismo, los desarrolladores de terminales no son necesarios en absoluto.
EventLoop está implementado en asyncio, y creo que el mismo principio se utiliza en otras bibliotecas asíncronas.
Incluso WinAPI, según tengo entendido, utiliza el principio de eventos para la asincronía.
Actualmente no podemos implementar el modo asíncrono completo utilizando herramientas estándar,
La razón es que el manejador OnTimer, por ejemplo, no controla la ejecución de la tarea y en su lugar ejecuta el bucle secuencialmente.
Es decir, el manejador carece del mecanismo de ejecución de tareas asíncronas.
Todo el mundo busca en Google el concepto de punto muerto.
En MQL5 añadir hilos romperá el sistema de pruebas y toda la nube de agentes se bloqueará.
Una solución a esta limitación es posible con las DLL. Si no quieres aprender C#, C++, C, Python - es tu problema. En el mundo actual, un programador debe conocer varios lenguajes para seleccionar correctamente una herramienta para una determinada tarea.
Los que conocen 1C no se consideran programadores. Lo mismo ocurre con MQL5.
Todo el mundo busca en Google el concepto de punto muerto.
En MQL5 añadir hilos romperá el sistema de pruebas y toda la nube de agentes se bloqueará.
Una solución a esta limitación es posible con las DLL. Si no quieres aprender C#, C++, C, Python - es tu problema. En el mundo actual, un programador debe conocer varios lenguajes para seleccionar correctamente una herramienta para una tarea concreta.
Los que conocen 1C no se consideran programadores. Lo mismo ocurre con MQL5.
Todo el mundo busca en Google el concepto de punto muerto.
En MQL5 añadir hilos romperá el sistema de pruebas y toda la nube de agentes se bloqueará.
Una solución a esta limitación es posible con las DLL. Si no quieres aprender C#, C++, C, Python - es tu problema. En el mundo actual, un programador debe conocer varios lenguajes para seleccionar correctamente una herramienta para una determinada tarea.
Los que conocen 1C no se consideran programadores. Lo mismo ocurre con MQL5.
Durante las pruebas, todas las tareas pueden ser resueltas una por una y los resultados pueden ser devueltos en determinados momentos (se puede esperar en el probador). No sólo se puede, sino que se debe, para que se corresponda con la realidad.
Me pregunto qué piensan los programadores de 1C al respecto. ¿Les interesa la opinión de otra persona?
Si el programa MQL multihilo rompe el sistema de pruebas, entonces ¿qué diferencia hay, si se adjunta a través de una DLL o una normal? En cualquier caso, tendrás que elegir entre las pruebas y el multihilo. Pero es mejor elegir dentro de MQL, porque la integridad es un plus para el programa.
Si un programa MQL multihilo rompe el sistema de pruebas, ¿qué diferencia hay en que esté enlazado mediante DLL o directamente? En cualquier caso, tendrás que elegir entre las pruebas y el multihilo. Pero es mejor elegir dentro de MQL, porque la integridad es un plus para el programa.
Hay una diferencia. Los DLL no están permitidos en la nube. Y los propios DLL están desactivados desde el principio. Al habilitar el permiso para las DLL, está abdicando de la responsabilidad de la ejecución segura del código.
EventLoop está implementado en asyncio, y creo que el mismo principio se utiliza en otras bibliotecas asíncronas.
...
Otras bibliotecas asíncronas no utilizan este principio.
Otras bibliotecas asíncronas no utilizan este principio.
Esto era sólo una suposición, no he comprobado dónde más se utiliza.
Buscando en Google qué lenguajes usan EventLoop, son Py, JS, Qt, probablemente alguno más.
La cuestión no es dónde se aplica sino en la propia tecnología sin usar hilos.
Entonces, ¿por qué no tomar prestada la tecnología e implementar en mql su EventLoop?