Programa Multi Hilo - Multi THREAD
Jesus Hurtado
multithread??? resulta que deseo realizar un proceso en varios servidores
a la vez. De forma normal, tendria que procesar servidor por servidor de
acuerdo vaya terminando uno por uno y eso me demanda tiempo al querer
procesar todo.
gracias por su ayuda.
-----------------------------------------------
PortalFox :: Nada corre como un zorro
http://www.portalfox.com
PortalFox - NNTP Forum Gateway
-----------------------------------------------
Esparta Palma
o DLLs y pasarte a hacer un pooling para ver si ha terminado (mediante
señales?), pero eso no es para nada Multithread. Sería como querer hacer
un rascacielos usando cimientos de bambú.
--
¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º
Espartaco Palma Martínez
SysOp http://www.PortalFox.com
México D.F.
MoBlogs!
http://weblogs.golemproject.com/esparta/
http://www.espartha.com/blog/
Rafael Vilar
lo hice hace mucho tiempo, en Visual Foxpro 7, y funcionaba bien. Tenía una
aplicación que al ejecutarse lanzaba un objeto COM+ que se mantenía
ejecutándose paralelamente.
El programa principal puede también "hablar" con el objeto COM+, mandar a
ejecutar funciones, leer sus propiedades, etc. Incluso puede detenerlo y
terminar su ejecución de manera remota.
Existía incluso la posibilidad de hacer un bind con propiedades del objeto
COM+ (event binding), de modo que cuando esa propiedad cambiara se lanzara
un evento en el programa principal. Aunque esto no lo llegué a hacer, sólo
lo leí.
También creo que podías comunicarte con un objeto COM+ que estuviera
ejecutándose en otra máquina en la red. Esto tampoco lo probé.
Eso sí, te advierto que no es algo trivial. Bueno, al menos no lo fue para
mi. Pasé un poco de trabajo para ponerlo a punto, pero cuando lo logré
estaba feliz, porque se te abren muchas posibilidades. Y supongo que ahora
que ese tema ha evolucionado, pues esté mucho mejor.
Si entras a msdn.microsoft.com/vfoxpro y haces una búsqueda por "COM+"
"foxpro" (pon las dos palabras en la búsqueda) encontrarás muchos artículos
que hablan cómo utilizar los COM+ en Visual Foxpro. Incluso hay algunos que
hablan de mejoras que se introdujeron sobre esto con Visual Foxpro 8.
A mi me sirvió muy bien un trabajo en tres partes que se llamaba
"Understanding COM+ with VFP". Supongo que ahora habrá cosas más nuevas,
pero estos tres artículos te ayudarán a entender bien este tema. Los links
son:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxtk01/html/ft01e1.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxtk01/html/ft01f20.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxtk01/html/ft01g13.asp
Bueno, suerte con esto. Y si por fin lo logras, me gustaría que contaras tus
experiencias.
Rafael
"Jesus Hurtado" <jhur...@distriluz.com.pe> wrote in message
news:%23%23Rjzshu...@TK2MSFTNGP10.phx.gbl...
Mario Cerón Charry
http://www.fpress.com/revista/num0305/art.htm
No es multitarea pura, pero funciona!!!
Mario
Rafael Vilar escribió:
Antonio Muñoz de Burgos y Caravaca
Aunque este tema da para escribir un artículo o un libro :-)
La implementación de hilos como tal, no existe en VFP, como bien lo indica
Esparta, VFP de forma directa no gestiona hilos.
Pero eso no significa, que no puedas tener procesos en paralelo aprovechando
la Multitarea del SO (sistema operativo), es evidente que el poder utilizar
esta opción del sistema dependerá en gran medida del tipo de aplicación que
se este realizando, para aplicar sencillez al mismo.
Intentando entender lo que planteas, entiendo que tu caso puede ser llevado
de muchas formas para que tengas un proceso real en paralelo.
Evidentemente por lo comentado, no podrás realizar hilos desde VFP, pero si
lanzar los tres procesos y que el modulo principal el responsable de lanzar
los procesos, no se quede bloqueado (en espera a la finalización) y que el
lanzar siguientes procesos no dependan o se inicien cuando finaliza uno de
ellos.
Esto sería totalmente viable y con multitarea real (la del Sistema), por
supuesto sería valido siempre cuando se cumplan con algunos requisitos, esto
dependerá de los requerimientos propios.
para que se entienda, por ejemplo; si el segundo proceso lanzado, necesita
de los resultados del primer proceso, aquí poco sentido tendría lo que
estamos comentando.
En este sentido, no das muchos detalles, por lo tanto puedo asumir que
hablamos de que tus procesos (los que deseas lanzar) no dependen la
información o retorno de algo para su ejecución.
La pregunta, cómo hacerlo:
Esto se puede realizar, realmente de muchas formas, desde la forma más
simple posible, hasta la creación de un sistema mucho más sofisticado, debe
entenderse que hablamos siempre de utilizar el Sistema MultiTarea del
Sistema, "no" de hilos ejecutados desde VFP (ya VFP no gestiona hilos)
Tampoco debemos confundir conceptos, con procesos Cliente/Servidor y/o
aplicados por diferentes medios WS, COM+, etc. aunque el resultado de lo
buscado, se pueda conseguir con alguna de esas formas, los conceptos son
totalmente distintos, es decir Cliente/Servidor, no es lo mismo que hablar
de Multitarea, ni es lo mismo que tener la capacidad de gestionar hilos,
etc..
Volviendo, al punto central de la conversación.
Entiendo, que para el caso que planteas, tener tres o x procesos en paralelo
utilizando la Multitarea del Sistema con VFP lo puedes hacer.
El caso solamente parte, de como "lanzar" dichos procesos para que sean
gestionados por el Sistema.
La forma más simple, es recurrir a la forma que te han comentado ya en este
hilo, lanza los .EXE
Consideración; cuando lances las aplicaciones, no la realices contra .DLL
por ejemplo con CREATEOBJECT, ya que en estos casos estaríamos en lo mismo,
debes aplicarlo con comandos que gestionen procesos independientes, el más
sencillo, por ejemplo : RUN
También puedes utilizar el API de Windows para lanzar los procesos y que
sean independientes, para que se pueda aplicar la MultiTarea del Sistema.
Como indicaba al principio, son varias las formas de atacar este tipo de
propuestas, la más sencilla la comentada, pero en algunas ocasiones es
necesario o se desea tener más control, todo ello dependerá de que es lo que
se desea realizar, realizando algo más complejo, es recurrir directamente al
API de Windows para realizar todo el proceso de lanzar las aplicaciones.
Pero aún en este caso comentado, si los requerimientos son mucho más altos,
existirán limitaciones.
Y tal vez como último paso, complicando un poco más, pero obteniendo algo
más sofisticado, es realizar un pequeño módulo en C o en otro lenguaje de
más bajo nivel que gestione los hilos, donde dicho módulos será el encargado
de realizar esta gestión de hilos, si este fuera el caso, aquí tus módulos
"no" tendrán que ser .EXE, sino utilizar el modelo Multi-threaded COM Server
(.DLL).
Cuando hablo de este módulo, es porque necesitamos una gestión de hilos y a
su vez utilizar la MultiTarea del Sistema.
Es decir los .EXE son válidos para lanzar los procesos con RUN,
ShellExecute, etc.., pero para un control de hilos el módulo (en un lenguaje
que lo soporte) ejemplo C, Delphi, etc. -> tus módulos en VFP deberán ser
.DLL
Consideración: Cuando hablo del modulo en C, no creas que hago referencia a
una macro aplicación, "no" ni muchos menos, el módulo puede ser tan básico,
como lanzar procesos y tener la capacidad de interacción con los mismos y
este módulo gestionado desde tu app. principal en VFP.
Resumiendo: Si tu necesidad es tener que lanzar, tres procesos y que el
inicio de ellos no dependa de la finalización del anterior y donde no
necesites interrelación entre dichos procesos, la solución sería tan simple
como lanzar los .EXE por ejemplo con RUN.
Saludos, Antonio Muñoz de Burgos
www.emans.com (Web realizada en vFoxPro)
eMans AC (Administrador Corporativo para SQL Server 2000&2005)
Manifestando el apoyo a la comunidad de Visual FoxPro.
"Jesus Hurtado" <jhur...@distriluz.com.pe> escribió en el mensaje
news:%23%23Rjzshu...@TK2MSFTNGP10.phx.gbl...
Fernando D. Bozzo
Muñoz, te puedo decir que los módulos ejecutables lanzados por un ejecutabl
central podrían comunicarse con este módulo, por ejemplo para devolver un
feedback de tarea terminada o estado de proceso, por medio de DDE. O sea que
el módulo central puede ser también un servidor DDE y los módulos clientes
ejecutados pueden, de forma asincrónica, enviar mensajes al principal.
Esta técnica todavía no la utilicé, pero estoy esperando tener un caso que
amerite su uso, porque debería funcionar muy bien y sin problemas. El único
requerimiento sería que el módulo principal tendría que estar en modo
stand-by (espera), sin procesar nada.
Saludos,
Fernando D. Bozzo
VFP6/SP5
Madrid/España
Recomendación:
Lea estos grupos de noticias con un cliente de newsgroup como Outlook
Express, este artículo lo guiará para configurarlo rápidamente:
http://www.panoramabox.com/GoPub.aspx?IdObj=2447
"Antonio Muñoz de Burgos y Caravaca" <emans...@emans.com> escribió en el
mensaje news:uCvT6npu...@TK2MSFTNGP12.phx.gbl...
Jesus Hurtado
Gracias por los alcances de Antonio, Rafael, Mario y "Esparta", en
realidad muchas gracias.
A ver mi escenario es el siguiente:
Tengo "n" servidores ubicados en distintas provincias del Perú pero todos
interconectados sin problema alguno. Lo que necesito es ejecutar un
script (procedimiento almacenado SQL) el cual realiza una serie de
procesos (insert, select, update) sobre cada servidor y al final me
devuelve un conjunto de resultados.
Cada uno de los procesos son independientes y no dependo del resultado de
uno para procesar el siguiente.
Una vez recuperado el resultado y almacenado en cursores VFP, procedo a
generar un solo archivo EXCEL con el total de los resultados.
Normalmente, este proceso me lleva (optimizado el script) unos 10 minutos
promedio en cada servidor, tomando en cuenta que son como 7 servidores, en
total se demora mas de hora, hasta hora y media, y como sabrán el tiempo
que pierdo en esperar que termine un proceso para recien iniciar el
siguiente y asi sucesivamente es tiempo perdido o muerto el cual lo deseo
aprovechar al máximo. Este es el gran motivo por el cual estaba pensando
en usar Multi Proceso o Multi THREAD en esta aplicación que en realidad es
una aplicacion grande donde una de las opciones es generar esta
información.
Miren... algo he logrado bajar el tiempo usando ejecución ASINCRONA del
proceso SQL con lo cual puedo ejecutar el mismo proceso en todos los
servidores al mismo tiempo, claro está programando un TIMER que me chequea
cada cierto segundos si el proceso SQL ha terminado.
Como sabrán, de todas maneras, una ejecución ASINCRONA es mucho mas lento
que una SINCRONA que es la que normalmente usamos asi que estaba
investigando en crear un proceso MULTI THREAD en donde cada proceso use
una ejecución SINCRONA y hacer reducir mucho mas el tiempo de ejecución.
Con respecto al comentario de Rafael Cerón, (claro está, sin desmerecer el
resto de comentarios) creo que mas o menos es por ahi el asunto.
Entiendo, segun lo que comentas, que debería crear un componente COM, es
decir, un archivo .DLL del proceso que se realiza y este archivo
ejecutarlo como multi proceso.
Si es asi, cual sería el mecanismo para lanzar este componente en un
proceso independiente.?
Amigos, realmente gracias por sus comentarios los cuales me han servido de
mucho para saber de este tema en VFP que creo pocos saben.
Debería tener VFP una funcion que permita preparar un escenario para poder
ejecutar multi procesos, no tan complicado, a la vez a no ser que esto
implique hacer una gran reingeniera en este software, con el cual llevo
bastantes años trabajando y me parece realmente excelente.
Saludos amigos y espero sus comentarios.
Atte,
Jesús Hurtado
Trujillo - perú
Victor Espina
pequeño programa en C# que tenga una funcion que reciba como parámetros
la cadena de conexión del servidor en donde deseas ejecutar el script, y
se encargue de conectarse con dicho servidor, ejecutar el script, tomar
el resultado y grabarlo en una tabla VFP.
Luego, el programa en C# puede crear un thread asociado a esa función
por cada uno de los servidores, y todo lo que tendria que hacer es
esperar a que los 7 threads se completen para entonces dar por terminado
el programa.
El código necesario en C# seria minimo y estarías aprovechando el tiempo
de procesador al máximo.
Si te interesa esta opción pero no tienes conocimientos de C#, yo puedo
echarte una mano con el programita.
Saludos
Victor Espina