🚀 go-pugleaf

	Joers!, y yo que cre�a que hab�a contestado. Esto qued� en
/var/spool/news/failed.postings 


>	Vamos a ver si rizamos el rizo un poco m�s. Dejando un poco de lado el
>que funcione. �Es buen estilo de programaci�n el que le padre no espere a que
>el hijo termine? Lo habitual, seg�n tengo entendido, es que el padre espere a
>por los hijoe (porque suelen hacer trabajos para �l), pero no s� si hay casos
>en que esto no sea posible y/o deseable. Mmm, un poco de filosof�a, me temo

	Pues por ejemplo, cuando quieres dejar un proceso en background :-)
(Esto parece la pescadilla que se muerde la cola).

	Es que esa es la t�cnica que se usa precisamente para este caso
concreto. Date cuenta que al terminar el proceso padre, se devuelve el control
al proceso que lanz� al padre (por ejemplo la shell bash).

	En el caso de los shell esto se puede conseguir con un "&" (que usa la
misma t�cnica), pero en el caso de procesos que lanzan otros procesos
(imaginaros el cron o el inetd) no se puede usar esto, ni se debe quedar el
proceso bloqueado esperando a que finalicen sus hijos (y ademas, no le interesa
lo que hagan los mismos). As� que hace un fork de si mismo, y el hijo lo lanza
y desaparece, mientras el pader puede seguir atendiendo peticiones.

	No s� si me explico, o lo l�o m�s.

                                Saludos de Javier (jcantero @ jet.es)

----
"La blasfemia es el �nico lenguaje entendido por todos los programadores"