Discussion:
fork() y procesos hijo
(demasiado antiguo para responder)
disuacidio
2004-12-25 12:32:42 UTC
Permalink
Hola grupo, veamos:
Estoy tratando de resolver un problema de sincronización de procesos, y por
lo que sé, cuando hago una llamada a fork() el proceso hijo hereda una copia
de los descriptores de archivoque hayan sido creados anteriormente, hasta
aquí bien, mi pregunta es: Si un proceso hijo crea una pipe, el proceso
*padre* puede leer (o escribir) en ella? Es decir, "sabe" de su existencia?
Creo que me explico, si no ya os pego el código. A ver si alguno me podeis
ayudar, que con el fork y el waitpid estoy un poco perdido, por más que leo
el MAN :-(
Gracias!
alidhaey
2004-12-25 13:52:40 UTC
Permalink
Como dices, el hijo hereda todos los descriptores de ficheros abiertos
(incluidos pipes, semaforos, buzones y sockets).
Pero a partir de entonces, lo que haga el hijo es independiente del
padre. Si el hijo abre un nuevo fichero, solo lo podra manipular el
hijo. Lo mismo pasara con las pipes y demás sistemas de
comunicación-sincronización basados en descriptores. Por ello, si
deseas que el hijo se comunique con el padre, la tubería (pipe)
debería ser creada por el padre.

Las llamadas al sistema wait y waitpid no sirven para nada en esto que
estamos hablando. Al padre solo le sirve para esperar a que un hijo
determinado (waitpid) o un hijo cualquiera (wait) terminen.

Un saludo
disuacidio
2004-12-25 16:43:37 UTC
Permalink
Aclarado, muchas gracias.
La cuestion es que se me pide que cree una pipe común y una individual para
cada hijo, y que cada hijo realice su trozo de calculo (en este caso la
media aritmetica del contenido de un archivo binario), y que acto seguido,
escriba en la pipe individual el resultado del cálculo, en la pipe común su
número de hijo, de forma que el padre, que está esperando a cualquiera de
los hijos termine, sabe dónde tiene que leer. Así que por tu respuesta
deduzco que estaba equivocado y:
1º- tengo que crear *todas* las pipes antes de las llamadas a fork(), y
cerrar luego los descriptores que no vaya a usar
2º- tengo que usar wait en lugar de waitpid

Lo que no sé hacer es "el padre debe esperar a que algún hijo escriba su
numero de hijo en la pipe común", pero ahora mismo me pongo a ver si lo
logro.
Gracias por la respuesta y saludos.

"alidhaey" <***@gmail.com> escribi� en el mensaje news:***@c13g2000cwb.googlegroups.com...
Como dices, el hijo hereda todos los descriptores de ficheros abiertos
(incluidos pipes, semaforos, buzones y sockets).
Pero a partir de entonces, lo que haga el hijo es independiente del
padre. Si el hijo abre un nuevo fichero, solo lo podra manipular el
hijo. Lo mismo pasara con las pipes y demás sistemas de
comunicación-sincronización basados en descriptores. Por ello, si
deseas que el hijo se comunique con el padre, la tubería (pipe)
debería ser creada por el padre.

Las llamadas al sistema wait y waitpid no sirven para nada en esto que
estamos hablando. Al padre solo le sirve para esperar a que un hijo
determinado (waitpid) o un hijo cualquiera (wait) terminen.

Un saludo
Alberto Giménez
2004-12-26 00:02:40 UTC
Permalink
Post by disuacidio
Lo que no sé hacer es "el padre debe esperar a que algún hijo escriba su
numero de hijo en la pipe común", pero ahora mismo me pongo a ver si lo
logro.
Gracias por la respuesta y saludos.
read(pipe_comun, buffer_msg, sizeof(buffer_msg));

:D
--
Luis Alberto Giménez
JabberID: ***@amessage.de
GnuPG ID: 0x3BAABDE1
alidhaey
2004-12-26 13:00:22 UTC
Permalink
Como te han contestado, para leer/escribir de una pipe, utilizas las
llamadas al sistema read/write de tratamiento de ficheros. Si te fijas,
un descritor de fichero es igual que un descritor de tuberia o un
semafaro. Ambos estan presentes a la tabla de ficheros abiertos del
proceso. Por eso se puede uitlizar esas funciones.

Cuando un proceso este leyendo de una tuberia mediante read(), si en la
tuberia no hay ningun dato disponible, el proceso se bloquea hasta que
algun dato llegue, en ese momento, se terminará de ejecutar la llamada
read() devolviendo el número de datos leídos.

Un saludo.

Loading...