Aprender y escribir juntos en MQL5 - página 17

 
Yedelkin:

Pregunta sobre la función Sleep(). ¿Entiendo correctamente que el uso de esta función en un Asesor Experto detiene la ejecución de sólo este EA y transfiere los recursos de la CPU (núcleo) a las siguientes tareas en la lista de tareas de este núcleo? En otras palabras, ¿es correcto que la función Sleep() no ralentiza el hilo en sí donde se está procesando el Asesor Experto, sino que funciona como un interruptor entre el Asesor Experto actual y otros programas recogidos por un núcleo particular?

Por lo que entiendo, si pongo Sleep(0), se cambiará, si pongo Sleep(milisegundos), el EA se detendrá durante un número especificado de milisegundos.

Al mismo tiempo, según tengo entendido, cada Asesor Experto es un hilo independiente y cada uno de esos hilos reclama tiempo de procesador (la comprobación del estado del hilo se realiza cada 100 milisegundos según la ayuda).

Así, si un hilo está inactivo, sea cual sea la razón, el tiempo de CPU se pasa a otro hilo y el estado del hilo que "decidió dormir" se comprueba después de 100 milisegundos.

PS

En cuanto a la distribución de los núcleos entre los hilos, depende de los desarrolladores.

 
Yedelkin:

Pregunta sobre la función Sleep(). ¿Entiendo correctamente que el uso de esta función en un Asesor Experto detiene la ejecución de ese EA solamente, y transfiere los recursos de la CPU (kernel) a las siguientes tareas en la lista de tareas de ese kernel? En otras palabras, ¿es correcto que la función Sleep() no ralentiza el hilo en sí donde se está procesando el Asesor Experto, sino que actúa como un interruptor entre el Asesor Experto actual y otros programas recogidos por un núcleo particular?

Cada experto se ejecuta en su propio hilo. Sleep() ralentiza este hilo. No hay unión con los núcleos (máscara de afinidad).
 
Yedelkin:

Pregunta sobre la estructura de MqlTradeResult. No he encontrado el campo de tiempo en él - tiempo de comprobación de la solicitud básica con éxito (o algo así). ¿Alguien recuerda si había una pregunta sobre la introducción de un campo de tiempo adicional en la estructura MqlTradeResult? Necesario para sacar una orden pendiente si de repente entra en el historial.

La petición no es clara. Si la orden ha sido abierta, almacenará la hora de apertura. ¿Por qué necesita el tiempo de respuesta del servidor?
 
sergeev:
La petición no es clara. Si la orden fue abierta, entonces almacenará la hora de apertura. ¿Por qué necesitas el tiempo de respuesta del servidor?

El destino del pedido se rastrea mediante el billete, ¿verdad? Sin embargo, la devolución del ticket por parte de la función OrderSend() no garantiza el éxito de la ejecución de la operación. Según la lógica del programa, basta con comprobar si mi billete ha aparecido entre los pedidos históricos y qué tratos se han realizado después de su colocación. Para ello me gustaría subir a la caché del historial la cantidad mínima de historia - es decir, desde el momento de la respuesta del servidor a la solicitud inicial, y no más. No necesitamos trabajar con las propiedades de una orden abierta - eso sería piezas redundantes de código. Es posible que el pedido ni siquiera se abra. Así, el tiempo de respuesta del servidor es necesario para descargar el tamaño (cantidad) óptimo de un historial fresco, utilizando la función HistorySelect(). Entonces, ¿está claro lo de "sacar una orden del historial"?

Según tengo entendido, aún no se ha planteado la cuestión de introducir un campo de tiempo adicional en la estructura MqlTradeResult.

 

Sobre Sleep() he entendido que el retraso del hilo del Asesor Experto no afecta a la ejecución de otros programas. Gracias.

 

Otra pregunta sobre Sleep(). El comentario dice: "No se puede llamar a la función Sleep() desde los indicadores personalizados, ya quelos indicadores se ejecutan en el hilo de la interfaz y no debería ralentizarlo". He leído el foro, pero sigo sin entender lo siguiente: la frase "no se puede llamar desde indicadores", ¿es una prohibición preestablecida o una recomendación al programador?

 
Yedelkin:

El destino del pedido se rastrea mediante el billete, ¿verdad? Sin embargo, la devolución del ticket OrderSend() no garantiza la ejecución exitosa de la operación.

ahem.... deberías echar un vistazo a un libro de texto sobre el envío de un pedido.
 
Yedelkin:

Otra pregunta sobre Sleep(). El comentario dice: "No se puede llamar a la función Sleep() desde los indicadores personalizados, ya quelos indicadores se ejecutan en el hilo de la interfaz y no debería ralentizarlo". He leído el foro, pero sigo sin entender lo siguiente: la frase "no se puede llamar desde indicadores", ¿es una prohibición preestablecida o una recomendación al programador?

prohibir
 
sergeev:
xxm.... deberías echar un vistazo a un libro de texto sobre el envío de un pedido.

Bueno, ya lo has entendido. Te lo digo meticulosamente, puedes comprobarlo: la función OrderSend() devuelve un valor booleano. En este caso, si la solicitud se comprueba con éxito, el ticket del pedido se escribe en la variable de la estructura MqlResult. Yo lo llamo "retorno de la función del ticket de pedido" para mí. Aquí está el enlace a la fuente:"Cuando se envía una solicitud de compra utilizando la función OrderSend(), se puede ver inmediatamente el ticket de la orden que se creó si la solicitud se comprueba con éxito.

Para la respuesta sobre la "prohibición" - gracias, lo tengo.

 
Yedelkin:

Bueno, ya lo has entendido.

Por desgracia, sigo sin entenderlo.

por alguna razón necesita tener un campo "tiempo" en la estructura de retorno. utilice el tiempo en el orden que aparece. Esto es suficiente para controlar un poco la historia.

Razón de la queja: