Multihilo - Multithread

[FiveWiDi]

Buenos días,

El blog de Rafa aún sigue aportando mucho.
Si tiras del hilo podrás profundizar en tema hilos https://xthefull.blogspot.com/2016/07/t ... vatos.html

Muchas gracias paquitohm, lo vi en su día, lo volveré a mirar.

[JoséQuintas]

Multithread es como tener múltiples EXEs.
De esta manera es claramente visible.

https://www.youtube.com/watch?v=KwK2DrLjc8A

Tenga en cuenta que si cierra el proceso principal, se cierra todo (se no haces nada diferente).
Mi uso de fivewin es así, desde una aplicación gtwvg, estoy empezando con la conversión.
No probé solo con fivewin.

[FiveWiDi]

Y cómo harían Ustedes para que un Timer se ejectuara en un hilo diferente.

Yo tengo este código:

Code: Select all | Expand

        DEFINE TIMER oVFTimer1 OF oVFWndTimer INTERVAL ( 1000 * nDelay ) ACTION ( oVFTimer1:Deactivate(), ;
                                                                                  lVFLaunchVerifactu( AMPAARRA, uSetGetValInArrBD( AMPAARRA, Nil, 84, Nil ) ), ;
                                                                                  oVFTimer1:Activate() )

¿Cómo hago para que este Timer se ejecute en su propio Hilo?

¿O debo crear el Hilo dentro de la función lVFLaunchVerifactu() ?

Muchas gracias,

[Antonio Linares]

Estimado Carlos,

Una reflexión apropiada sería distinguir lo que hace un timer de lo que hace un "hilo de ejecución" y ver hasta que punto son compatibles y deseable el usarlos juntos.

Un timer hace que cada x tiempo se genere un evento desde el cual se ejecuta un proceso. Es decir, todo se para hasta que se completa la ejecución de ese proceso.

Un "hilo de ejecución" lo que hace es "bifurcar" (un tanto artificialmente) la ejecución principal del programa. Es decir, es como si en vez de existir una CPU, existiesen más de una CPU. En realidad la CPU principal "reparte" el tiempo entre cada proceso, aunque a todos los efectos pareciese que se ejecutan en paralelo.

Finalmente la pregunta es: ¿ Que es lo que necesitas hacer para saber que camino tomar ?

[Antonio Linares]

Tiene sentido lo que preguntas

El evento del timer solicitaría que se ejecute un proceso, pero el proceso se ejecutaría en un hilo diferente para no enlentecer la ejecución de la app principal.

Es este el efecto que buscas ?

[Antonio Linares]

Simplemente así:

Code: Select all | Expand

DEFINE TIMER oVFTimer1 OF oVFWndTimer INTERVAL ( 1000 * nDelay ) ACTION hb_threadStart( { || lVFLaunchVerifactu( AMPAARRA, uSetGetValInArrBD( AMPAARRA, Nil, 84, Nil ) ) } )

Si usas hbmk2 para construir tu app (es lo más recomendable) recuerda usar el flag -mt para que se construya con soporte de ejecución multihilo

Ojo con el uso de variables compartidas y de DBFs ya que tendrás que usar "mutex"es (semáforos) para aplicar la prioridad deseada.

[Carles]

Bones,

Yo creo q quiere crear un pool de impresiones o imprimir en 2 plano mientras el progeama sigue con la suya. Si es asi lanzar un hilo para ejecurar la tarea y listos.

C.

[xmanuel]

Pienso como Charly.
Además como la impresión no necesita ninguna tutela solo tienes que enviarlo a un subhilo y te olvidas, De hecho deberías tener solo un hilo de impresion al cual enviar las peticiones para el trabajo de imprimir.

Pero para procesos repetitivos en el tiempo, el Timer debería estar en el principal.

[FiveWiDi]

Hola todos,

El caso práctico es que es una aplicación de facturación que cada 'n' segundos enviará la información ( shellexecute(CURL.EXE) ) de las nuevas 'facturas' a Verifactu.

Es decir, una aplicación que deseo que mientras el usuario hace sus labores habituales, no note que hay un proceso que está enviando información a Verifactu.
Tal como dice Antonio.

Por otro lado, de las DBF usadas en ese proceso, unas sólo las actualiza ese mismo proceso, otras sólo las lee y una última es alimentada por el 'usuario' añadiendo datos de facturas desde el proceso de facturación. Todas se abren (Shared en todos los procesos de la aplicación) y cierran en este proceso y con alias diferentes.
Y de la variables 'compartidas', no se actualiza ninguna en ese proceso y normalmente en otros procesos 'habituales' tampoco. Son de configuración.

Hoy en día estoy compilando con un make.rmk con las lib -mt, aunque no lo estaba usando.

A ver si hoy o mañana pruebo como va.

Muchas gracias a todos.

[paquitohm]

Hola,

Ese tipo de situaciones lo he solucionado rellamando al ejecutable con un parametro para que haga una funcion especifica

En este caso, en el timer, pondria una llamada al ejecutable asi o parecido RUN Algo.exe /ENVIO_VERIFACTU y en el main cogeria el parametro
Esto asegura una correcta comparticion de recursos

Sin duda que el uso de thread es más elegante, pero quizás no más practico. ¿ Que es más elegante y qué es más practico ? ¿ Un coche electrico o un coche de combustion ? Pues eso

[FiveWiDi]

Yo tengo 3 escenarios y 3 soluciones, 2 funcionan y la tercera está en desarrollo.

a) Un puesto que factura algunas veces a la semana: Verifactu funcionando según se emite factura (on line).

b) Varios puestos que pueden facturar: Verifactu es un ejecutable que se lanza al arrancar el SIF ( des de la aplicación 'principal' Shellexecute( loquesea.exe ) o manualmente desde el escritorio Windows) y que va buscando según un Timer.

c) Aplicación SIF externa que dejará información en unas DBF, y un ejecutable externo que capturará esta información y hará toda la gestión para enviar a Verifactu, buscará según un Timer. El SIF y Verifactu son de desarrolladores diferentes. Esta solución la quiero entregar antes de Navidad.

Seguimos,

[TOTOVIOTTI]

Hola Estimados...
una consulta porque no lo entiendo bien... a ver si me desburran...

Puedo usar un "thread" cuando inicio mi programa principal?
Ejemplo, hago la presentación de mi sistema y llego a menú principal,
mientras tanto, puedo ir haciendo un "thread" de una lectura de una tabla secundaria, y me guarde
esos datos en la memoria?

Espero se entienda lo que quiero hacer...

Muchas gracias!!

Roberto