´Gurús de Linux, echadme un cable: ¿las fifos tocan la memoria principal o sólo RAM?

[3L_S4N70]

Hola peña. La duda parte de este hilo: (http://www.gp32spain.com/foros/showthread.php?t=69466), sólo que es otro rollo realmente.
Visto lo que necesitaba, me decanté por utilizar fifos (menos versátil, pero siendo siempre sistema Linux, de sobra). Necesitaba comunicar dos programitas.

Problema: rizando el rizo, mkfifo me genera un archivo en la memoria principal, que es Flash (corregidme si me equívoco). El tema está en que si leo y escribo en ella, al estar en una memoria Flash, me la acabaré cepillando en ná y menos. ¿Algún gurú de Linux me puede indicar si es posible hacerme la fifo sobre RAM, o hacer algo parecido, sin estar todo el rato sobre la Flash?

Mirando un poquito por ahí, no entiendo mucho, a ver, segun este foro: http://www.unix.com/shell-programmin...h-using-2.html
las fifos corren en RAM. No obstante, el archivo se genera de todas todas, ¿no? Yo cuando corro el programa que me genera la fifo, me hace un archivo visible en la memoria principal. ¿Acaso evitaría j0der la Flash con un exceso de lecturas y escrituras simplemente haciendo un archivo de tuberia y dejandolo siempre ahi? De tal manera, que cada vez que escribiese sobre él, eso va a la RAM, pero no generándolo y eliminándolo cada vez que ejecuto el programilla, que eso sí que va a memoria principal, ¿no?
Bueno, creo que con esto tengo un poco de cacao, a ver si alguien me saca de dudas.

Mil gracias de antemano, y un saludo

[Jurk]

sin saber mucho de linux, pero sabiendo los problemas de los programas de GP2x (kernel Linux) que no guardaban partida a veces... supongo lo siguiente:

Linux tiene un sistema de escritura de archivos asincrono, es decir, que escribe sobre las unidades fisicas cuando le da la gana si no le obligas a escribir el un momento determinado. De mientras trabaja con la RAM.

Lo mas seguro es forzar la escritura cuando tu lo quieras, utilizando los comandos necesarios para eso

[juanvvc]

Las FIFOS con nombre no se escriben en memoria. En Windows no son persistentes, pero en Unix si y usan ese "archivo" para ponerse de acuerdo en el nombre y encontrarse al conectarse. Una vez creado el archivo no se vuelve a escribir nada en disco, toda la comunicación entre procesos es por RAM.

Civantoz, las FIFO se pueden crear en cualquier parte con mkfifo, no solo en /dev. De hecho en /dev suele usarse para eso mknod, que también crea FIFOs pero no es su función principal (ni recomendada) Y lo que dices de los socket es perfectamente posible también. De hecho, así es como se implementan en Windows las FIFO con nombre así que es posible que le interese para mejorar la portabilidad.

Aún así creo recordar que no puedes escribir en un socket si no hay nadie escuchándolo, cosa que sí que puedes hacer en una FIFO. Los datos en la FIFO quedan en memoria hasta que alguien llegue y los lea, mientras que en los sockets ambos programas tienen que estar ejecutándose a la vez.

[Drumpi]

Piensa que en Linux todo son o directorios o ficheros: si no lo es, no existe. Lo digo porque cosas como la pantalla, el ratón, la impresora, el puerto serie, todos son ficheros, y cuando lees/escribes en ellos no lo haces sobre el disco duro/flash.

Con las FIFO pasa igual, es un recurso SW del SO, como mucho contendrá info de dónde encontrar los datos que guarda, pero será en la RAM. Símplemente se guarda en el disco duro porque es un sitio que no varía con el tiempo (la memoria RAM está contínuamente reajustándose, en los discos duros sólo cuando se lee/escribe directamente).

Lo de los sockets creo que tendría que mirarlo, pero creo que existen no bloqueantes, si no, los navegadores se quedarían pillados si los abrimos sin red ¿no? (ni qué decir cuando en mitad de la comunicación uno de los lados se cae...).

[juanvvc]

Lo de los sockets creo que tendría que mirarlo, pero creo que existen no bloqueantes, si no, los navegadores se quedarían pillados si los abrimos sin red ¿no? (ni qué decir cuando en mitad de la comunicación uno de los lados se cae...).

En un socket no bloqueante, cuando intentas leer y no hay datos no te quedas esperando a que haya. A la hora de escribir da igual que sea o no bloqueante porque escribe igualmente en el buffer local. Pero aunque parezca de perogrullo, antes de que sea o no bloqueante tiene que ser socket Si no hay nadie escuchando al otro lado no puedes ni siquiera abrir el socket y por tanto mucho menos leer o escribir de él, bloqueante o no.

En el caso del navegador que se abre sin red, se queda esperando a que empiece el handshake y como no tiene red ni siquiera puede abrir el socket. Por tanto no puedes escribir ni leer en él porque en realidad no tienes socket, te has quedado en la línea de antes En el caso de la comunicación que se cae, los timers y buffers de tu driver TCP local hacen su función y podrás escribir en tu buffer local mientras no salte el timer, pero en cuanto lo haga la información se perderá y el socket se cerrará. En este caso tu programa recibirá un error que tendrá que manejar.

Lo diferencia con FIFO es que sí que puedes abrir y leer o escribir aunque no haya nadie al otro lado. "Leer" en este caso es como en cockets abrir un puerto y esperar a que llegue una conexión y entonces ponerse a leer, pero las FIFOs son mucho más sencillas que los sockets de programar y además consumen menos recursos, así que suele ser una buena idea usarlas en vez de sockets. También pueden hacerse o no bloqueantes. Lo malo de las FIFOs es que no son tan portables como los sockets entre sistemas operativos.

[3L_S4N70]

Gracias cracks , era lo que necesitaba confirmar. Sospechaba que sería absurdo tirar de memoria principal, pero como el archivo en sí se generaba en la misma, me hacía dudar mucho.

Respecto a lo de los sockets, a decir verdad, no me interesa tanto la portabilidad, ya que es para un sistema empotrado que corre con una versión de Linux, y que si quisiera portarlo a otro sistema, requeriría mucho más trabajo (un rediseño completo, quizá) que el simple hecho de adaptar mis programitas.

Otra duda que lanzo: ¿qué implica lo de bloqueante o no en una fifo? ¿Se refiere a que el programa que escribe/lee de la misma, no espera a que se leído/escrito por el otro, sino que lo va escupiendo y lo deja ahí sin interesarse más por ello y sigue haciendo cosas, sin quedarse "mirando como un bobo" a que el otro lo coja? Si es eso, ¿cómo puedo hacerlo (de ser eso, creo que trabajo con bloqueantes ahora mismo)? Lo que hago es generarlas con un prgramita en C (ahora mismo, que trabajo sobre disco duro, cuando esté sobre la Flash, lo que haré será generarlo, y desde los programitas tan sólo escrbir/leer). La duda es cómo le digo que sean bloqueantes o no (si es lo que he supuesto que es), ¿en el momento de generarlos, o al abrirlos para utilizarlos?

Muchísimas gracias

[juanvvc]

FIFO no bloqueante es exactamente eso que dices. Se configura para que sea no bloqueante pasando el parámetro O_NONBLOCK al abrir la FIFO con open(). No sé si puede hacerse con fopen() y demás funciones de la familia, pero no lo veo en la documentación.

El comportamiento exacto de la FIFO cuando no es bloqueante parece que no está en POSIX, así que cada sabor de *nix hace lo que le viene en gana. Por las pruebas que he hecho, Linux no bloquea la lectura ni la escritura, pero lo que escribes sin que haya nadie escuchando lo pierdes.

[3L_S4N70]

Ostras, si se pierde en lugar de quedarse esperando a ser leído, de poco me vale. Tendré que acelerar el ratio de lecturas y escrituras. No obstante, tendré que echarle un vistazo a ver cómo se hace en OpenWRT, quizá tenga suerte, aunque lo dudo.

Mil gracias de nuevo.