Programación asíncrona y multihilo en MQL - página 16

 
Roman:

Ya te escribí, estás tratando de construir un NS, ¿no necesitas asincronía en este caso?
Pero está construyendo NS sobre funciones de activación simples, por lo que no ha encontrado una falta de concurrencia.
Pero cuando empieces a construir modelos globales de NS, entonces entenderás la belleza de la asincronía.

mal ejemplo - ¡no es necesario!

@Roffild ya escribió en el hilo"En el mundo actual, un programador debe conocer varios lenguajes para poder elegir la herramienta adecuada para una determinada tarea. "

¡esto es verdad!

En MQL no hay opción de paquetes para MQL - sólo AlgLib - Quiero considerar un ejemplo, encontrado en el hubra, tomo y conecto C# o Python a MQL - eso es todo, hago lo que quiero hacer, no portar código a MQL

Hoy en día, los lenguajes de programación no son interesantes por sus características, sino por los marcos de trabajo ya creados. - Si en MQL habrá nuevos paquetes MQL, entonces habrá otras tareas y problemas.

ZS: una vez más en mis dedos, te aferras a "la idea de fx" que surgió de los lenguajes multiplataforma Python y Java, el sacrificio por la portabilidad y flexibilidad del lenguaje fue la pérdida de rendimiento, ahora estos lenguajes se han sobredimensionado con diferentes formas de aumentar el rendimiento, pero en los lenguajes tipo C los desarrolladores siempre logran el máximo rendimiento y no hay necesidad (en la mayoría de los casos) de dividir la tarea en hilos separados (las tareas cliente - servidor no cuentan, ahí el problema es la tasa de intercambio de datos y esto es otro específico)

 
Igor Makanu:

mal ejemplo - ¡no es necesario!

@Roffild ya escribió en el hilo"En el mundo actual, un programador debe conocer varios lenguajes para poder elegir la herramienta adecuada para una tarea concreta. "

¡esto es verdad!

En MQL no hay opción de paquetes para MQL - sólo AlgLib - Quiero considerar un ejemplo, encontrado en Habra, tomo y conecto C# o Python a MQL - eso es todo, hago lo que quiero hacer, no portar código a MQL

Hoy en día, los lenguajes de programación no son interesantes por sus características, sino por los marcos de trabajo ya creados. - Si en MQL habrá nuevos paquetes MQL, entonces habrá otras tareas y problemas.

ZS: una vez más en tus dedos, te aferras a "la idea de fx" que surgió de los lenguajes multiplataforma Python y Java, el sacrificio por la portabilidad y flexibilidad del lenguaje fue la pérdida de rendimiento, ahora estos lenguajes se han rodeado de varias formas de aumentar el rendimiento, pero en los lenguajes tipo C los desarrolladores siempre logran el máximo rendimiento y no hay necesidad (en la mayoría de los casos) de dividir la tarea en hilos separados (las tareas cliente - servidor no cuentan, ahí el problema es la velocidad de intercambio de datos y esta es otra especificidad)

Usted ignora constantemente las siguientes cosas:

1. La distribución de programas que utilizan conexiones externas no puede hacerse a través del Mercado.

2. Los programas que utilizan conexiones externas requieren que el usuario sea un "profesor" para conectar todo correctamente. Las instrucciones de uso de dicho programa son un lío.

3. Los programas que utilizan conexiones externas sólo son aptos para uso personal, lo que limita mucho el sentido de su creación.

4. Los programas de uso personal son de menor calidad que los de venta, porque puedes hacer cualquier cosa por ti mismo... y no puedes ser el mismo experto en varios idiomas a la vez. Algunos idiomas los conocerás de la quinta a la décima lengua y eso afectará a la calidad del producto.

5. Hay muchas tareas que requieren asincronía y multihilo. Los programas MQL aún no han alcanzado estas tareas, pero eso no significa que no deban esforzarse por conseguirlas.

 
Roman:

...
Lo que logra la asincronía en un solo flujo.

No, bueno, la asincronía sin el multithreading es realmente una tontería, se necesita al menos un hilo adicional. Creo que tu EventLoop se puede hacer mediante indicadores cargables. Comunicación entre indicadores expertos a través de sockets, por ejemplo. Se creó una tarea, se enganchó el indicador, se envió la tarea, el indicador informó de la ejecución, solicitamos el estado de la tarea al Asesor Experto, borramos el indicador. A través de muletas, pero multihilo al fin y al cabo.

 
Roman:

Sí, ese artículo es muy bueno, para una única solución, para pensar en ello, tal vez se pueda exprimir algo más de este enfoque.
He decidido la dirección de mi problema, gracias a Andrey por el consejo.

El hecho de que hayas leído un artículo es bueno.

Romano:

No hilos, a saber, las llamadas sin bloqueo a través de funciones de colback, controlado por EventLoop.
Esto logra la asincronía en un hilo.

¿Cómo se las arregló para no encontrarlo en la documentación?

¿Por qué no lo lees?

 
Реter Konow:

Usted ignora constantemente las siguientes cosas:

Tú y yo tenemos tareas diferentes, no tienes en cuenta que hay 2 grandes pasos en la escritura de software: el desarrollo de software y la implementación en sí.

El desarrollo de software requiere soluciones preparadas: lleva tiempo; si durante el desarrollo resulta que el software no va a realizar sus tareas según lo previsto, va a la basura. Y la implementación en sí es un trabajo mecánico para las capacidades de una plataforma particular.


ReTeg Konow:

5. Hay muchas tareas que requieren asincronía y multihilo. Los programas MQL aún no han alcanzado estas tareas, pero esto no significa que no deban esforzarse por conseguirlas.

Bien, ahora vamos con usted:

Responde a la pregunta ¿por qué lo necesita elterminal de comercio?

 
Koldun Zloy:

El hecho de que hayas leído un artículo es bueno.

¿Cómo se las arregló para no encontrarlo en la documentación?

¿Por qué no lo lees?

Imagina que no lo encuentras.
Buscando por callback y eventloop no se encuentra nada de eso en la documentación.
Si no te importa, por favor, dame un enlace sin sarcasmo.

 
Igor Makanu:

1. Tú y yo tenemos tareas diferentes; no tienes en cuenta que hay dos grandes etapas en la escritura de software: el desarrollo y la implementación.

El desarrollo de software requiere soluciones preparadas; esto lleva tiempo; si durante el desarrollo resulta que el software no va a realizar sus tareas según lo previsto, se echa a perder. Y la implementación en sí es un trabajo mecánico para las capacidades de una plataforma particular.


Bien, ahora vamos con usted:

2. Responda a la pregunta: ¿por qué lo necesita elterminal de comercio?

1. Todo lo que hago es desarrollo. Apenas 6 años de desarrollo continuo que no entiendo lo que es. )) Creo que las soluciones externas ya hechas, arrancadas del contexto de otros programas o abstraídas de algunos otros programas, se integran mal en la estructura de un código altamente especializado y pueden resultar muy desordenadas. En este caso, la mano de obra es mayor que en el desarrollo de una solución propia y la calidad final del código es menor. Por no hablar del potencial de desarrollo. Estas son las realidades del desarrollo. Pero, esto es irrelevante para nuestra pregunta. De hecho, ¿qué tiene esto que ver?

2. Se está equivocando de pregunta. La pregunta principal es "¿Por qué lo necesita el usuario final?". Porque al usuario siempre se le quedan cortas las prestaciones que se le ofrecen. Por lo tanto, hay que añadirlos para que no pierdan el interés. Si nos quedamos sin posibilidades y no podemos añadir nuevas por limitaciones técnicas, el usuario abandonará. Se necesitan oportunidades para mantener a los usuarios en el terminal y la distribución de software es necesaria para este propósito. Por lo tanto, los programas que no se pueden distribuir no tienen sentido para la comunidad, independientemente de los lenguajes que utilicen.


De hecho, sólo mira sus propias necesidades y no tiene en cuenta las de los demás usuarios. Usted no quiere ni quiere hacer negocios en esta comunidad, y sólo transmite la motivación de ganar dinero en el mercado. Y se puede ganar dinero en el mercado sin ningún tipo de software.

 
Igor Makanu:

mal ejemplo - ¡no es necesario!

@Roffild ya escribió en el hilo"En el mundo actual, un programador debe conocer varios lenguajes para poder elegir la herramienta adecuada para una determinada tarea. "

¡esto es verdad!

En MQL no hay opción de paquetes para MQL - sólo AlgLib - Quiero considerar un ejemplo, encontrado en el hubra, tomo y conecto C# o Python a MQL - eso es todo, hago lo que quiero hacer, no portar código a MQL

Hoy en día, los lenguajes de programación no son interesantes por sus características, sino por los marcos de trabajo ya creados. - Si en MQL habrá nuevos paquetes MQL, entonces habrá otras tareas y problemas.

ZS: una vez más en tus dedos, te aferras a la "idea fija" que surgió de los lenguajes multiplataforma Python y Java, el sacrificio por la portabilidad y la flexibilidad del lenguaje fue la pérdida de rendimiento, ahora estos lenguajes se han rodeado de diferentes formas de aumentar el rendimiento, pero en los lenguajes tipo C los desarrolladores siempre logran el máximo rendimiento y no hay necesidad (en la mayoría de los casos) de dividir la tarea en hilos separados (no se incluyen las tareas cliente - servidor, ahí el problema es la velocidad de intercambio de datos y esta es otra especificidad)

Igor, a veces te contradices.
La última vez que escribiste que la velocidad de cálculo de mql es comparable a la de C++
De acuerdo, esto es efectivamente cierto y mucha gente lo sabe.
Pero luego pones un ejemplo de conexión de frameworks de terceros a cálculos de puertos, como lo pones en lenguajes atrasados.
Y usted aboga por la conectividad de los paquetes de terceros. ¿Así que sacrifica la velocidad por un marco de trabajo estándar?
Y así, como escribió Peter, pierdes completamente la portabilidad de tu programa.
No es una buena solución. Para uso personal, sí, pero no para uso masivo.

 
Roman:

Imagina que no lo encuentras.
La búsqueda de callback y eventloop no encuentra nada parecido en la documentación.
Si no te importa, dame un enlace sin sarcasmos innecesarios.

No hay que hacer una búsqueda, hay que leer todo. Seguro que hay muchas sorpresas para ti.

No habrá enlaces.

Aquí he ayudado más de una vez a gente que al menos ha intentado hacer algo por sí misma.

¿Y qué has hecho?

¿Sólo te sientas y cuidas tu boca en el foro?

Bueno, te estoy ayudando con eso.


 
Sólo los vendedores del mercado pueden necesitar arroyos en MKL. Para todos los demás, ya hay flujos. ¿Necesita un procesamiento complejo? - Pasa los eventos a una DLL, crea y separa un flujo y libera el flujo de la terminal, y podrás procesarlos siempre).
Hay que decir que la mayoría no podrá con los hilos, y que un centenar o dos de todos los usuarios de ICL lo necesitarán. ¿Se molestaría MKL por un centenar de programadores que quieren operar en Market?