🚀 go-pugleaf

Cron escribi�:

> fork() crea un proceso hijo para ejecutarse de forma concurrente al padre.
> Los Threads ejecutan hilos de forma concurrente en el mismo proceso (no es
> necesario crear procesos hijos) (eso creo).
>
> Salu2
>
> "Swat" <ghe_rivero@yahoo.es> wrote in message
> news:98in5i$4g2$1@titan.bt.es...
> > Se que no tiene nada que ver, pero, alguien me podria decir la dicerencia
> > en fork y threads?
> >

En comun tienen que ambos son dos lineas de ejecucion de codigo.
La diferencia es mas sutil, los procesos tienen tres espacios de memoria, el
c�digo, el cumulo ('heap' en ingles) y la pila. Cuando creamos un proceso hijo
los unix modernos (y entre ellos linux) generan una entrada nueva dentro de la
tabla de procesos del kernel, por lo que pasan a ejecutarse dos programas con
la misma memoria. En cuanto uno de ellos escribe algo (modifica el valor de
alguna variable) el kernel genera para el proceso hijo una heap y una pila
nuevas. El espacio asignado al codigo se comparte.

Con los threads se pretende ir un paso mas alla. Al crear un thread se crea
una nueva entrada en la tabla de threads (lo cual es mucho decir pues depende
de la implementacion hace una cosa u otra), asi cuando se separa la ejecucion
de los threads, se duplica el espacio de pila, pero el heap se mantiene comun
(al igual que el codigo). Esto significa dos cosas:
a) el crear un thread es mas rapido, pues solo se duplica la pila (a la hora
de la verdad, las implementaciones de threads en linux no son muy buenas y la
diferencia de velocidad es minima, ademas de que la mayor  cantidad de
variables estan en pila)
b) la comunicacion entre procesos es mas sencilla, aqui esta la verdadera
ventaja. Un thread hace un malloc, escribe algo en ello y ya est� accesible a
todos los threads de ese proceso.

Respondiendo a la pregunta original, de no ser que exista MUCHA carga
(Y entonces miraria un cluster) y mucha comunicacion entre las ejecuciones
usaria multiprocesos por :
a) los programas no son perfectos, un fallo de memoria (un puntero loco) en un
sistema multiproceso te bloquea al cliente que atiendes, en un sistema
multithread manda a todos los clientes al garete.
b) en entornos multithreads es mas sencillo la comunicacion entre los hilos,
pero hay que tener cuidado, los accesos tiene que ser serializados (evitar que
dos hilos ataquen al mismo recurso compartido a la vez), nos evitamos la
memoria compartida y los semaforos y entramos en los mutex. El grado de
complicacion es similar pues lo que complica la programacion es el reparto de
los recursos entre los clientes.


Espero haber ayudado

Angel

Opositor.com