...una imagen de The Thing para el remake de Irrational Man: empezamos bien... |
Repitiendo la estructura del viejo post (y si no, ¿qué remake sería?) he dividido todo en dos partes: en la primera describiré, a modo de especifica funcional, el header file (libmmap.h) y un ejemplo de uso (data.h, datareader.c y datawriter.c). En la segunda entrega describiré la implementación real de la librería (libmmap.c).
Empezamos: vamos a ver el header-file, libmmap.h:
#ifndef LIBMMAP_H #define LIBMMAP_H #include <semaphore.h> #include <stdbool.h> #define MAPNAME "/shmdata" // estructura del mapped-file typedef struct { sem_t sem; // semáforo dei sincronización accesos bool data_ready; // flag de data ready (true=ready) size_t len; // longitud del campo data char data[1]; // datos a compartir } ShmData; // prototipos globales ShmData *memMapOpenMast(const char *shmname, size_t len); ShmData *memMapOpenSlav(const char *shmname, size_t len); int memMapClose(const char *shmname, ShmData *shmdata); int memMapFlush(ShmData *shmdata); int memMapRead(void *dest, ShmData *src); void memMapWrite(ShmData *dest, const void *src); #endif /* LIBMMAP_H */Simple y autoexplicativo, ¿no? la nuestra librería utiliza una estructura de datos ShmData para mapear el mapped-file: aquí notamos de inmediato la primera gran mejora obtenida: hay un semáforo (un POSIX unnamed semaphore) para sincronizar los accesos a la memoria, lo que hace que la nuestra librería sea adecuada para un verdadero uso multitask (y multithread), que era el primer objetivo programado. El mecanismo de sincronización lo he elegido cuidadosamente entre los diversos disponibles: tal vez un día escriba una publicación específica sobre el tema, pero, por el momento, me limitaré a decir que el método elegido es simple de implementar, muy funcional y perfectamente adecuado para el propósito que hay que lograr (¿y esto es suficiente, no?).
El flag de data_ready se usa (protegido por el semáforo) para indicar la disponibilidad de nuevos datos a leer. Luego tenemos, dulcis in fundo, los campos len y data que nos llevan al segundo objetivo que había establecido: los datos intercambiados son, ahora, genéricos, con formato y longitud que se deciden a nivel de aplicación. Nótese, de hecho, que el campo data es un array de dimensión 1: esto es una especie de truco (a usar con las debidas precauciones) bastante utilizado en C para tratar datos genéricos de forma y longitud no disponibles a priori. En nuestra struct el campo debe colocarse, obviamente, como el último miembro, transformándola así en una especie de estructura de tamaño variable. Sin embargo, en el próximo post veremos mejor cómo funciona todo.
libmmap.h termina con los prototipos de las funciones que componen la libreria: tenemos dos funciones de apertura, que nos permiten abrir un mapped-file en modo Master o Slave (en el próximo post veremos el motivo de esta doble apertura); luego tenemos una función de cierre, una función de flush y, por supuesto, dos funciones para escribir y leer datos. Estas dos últimas funciones confirman el discurso de generalidad descrito anteriormente: las variables de read/write son de tipo void*, por lo tanto, son adecuadas para aceptar cualquier tipo de datos. Como el formato de los datos a intercambiar se mueve al nivel de la aplicación, he escrito un header-file (como ejemplo), data.h, que está incluido en las dos aplicaciones que se comunican:
#ifndef DATA_H #define DATA_H // definición estructura data para aplicaciones de ejemplo typedef struct { int type; // tipo de datos int data_a; // un dato (ejemplo) int data_b; // un otro dato (ejemplo) char text[1024]; // testo de los datos } Data; #endif /* DATA_H */Como podéis ver he elegido utilizar una estructura de datos que incluye un campo de texto, pero se puede intercambiar cualquier cosa, también solo un simple int, por ejemplo. Ahora vamos a ver la primera aplicación de uso, datawriter.c:
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include "libmmap.h" #include "data.h" #include "mysleep.h" // main del programa de test int main(int argc, char *argv[]) { // abre mapped-file ShmData *shmdata; if ((shmdata = memMapOpenMast(MAPNAME, sizeof(Data)))) { // file abierto: start loop de escritura for (int i = 0; i < 100; i++) { // compone datos para el reader Data data; snprintf(data.text, sizeof(data.text), "nuevos datos %d", i); // escribe datos en el mapped-file memMapWrite(shmdata, &data); printf("he escrito: %s\n", data.text); // loop sleep mySleep(100); } // cierra mapped-file memMapClose(MAPNAME, shmdata); } else { // sale con error printf("no puedo abrir el file %s (%s)\n", MAPNAME, strerror(errno)); return EXIT_FAILURE; } // esce con Ok return EXIT_SUCCESS; }Simple, ¿no? Abre el file compartido en la memoria (en modo Master) y lo usa para escribir datos (en loop) para la otra aplicación de test, datareader.c:
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include "libmmap.h" #include "data.h" #include "mysleep.h" // main del programa de test int main(int argc, char *argv[]) { // abre esperando que un writer abra come master el mapped-file ShmData *shmdata; while ((shmdata = memMapOpenSlav(MAPNAME, sizeof(Data))) == NULL) { // acepta solo el error de file todavía no existente if (errno != ENOENT) { // sale con error printf("no puedo abrir el file %s (%s)\n", MAPNAME, strerror(errno)); return EXIT_FAILURE; } // loop sleep mySleep(100); } // file abierto: start loop de lectura for (int i = 0; i < 100; i++) { // busca datos a leer en el mapped-file Data data; if (memMapRead(&data, shmdata)) { // enseña los datos leidos printf("me has escrito: %s\n", data.text); } // loop sleep mySleep(100); } // cierra mapped-file y sale con Ok memMapClose(MAPNAME, shmdata); return EXIT_SUCCESS; }El reader es, como se nota, una aplicación especular del writer (lee en lugar de escribir). Notar que, en ambas aplicaciones, se testean los errores en las funciones de open y se cierra (si necesario) la ejecución enseñando el error con strerror(): esto es posible porque (como veremos en el proximo post) las funciones de apertura salen en caso de error de las funciones de la libc que usan internamente, y, en ese punto, la descripción del error que ha ocurrido está disponible con errno (pero de esto hemos hablado extensamente en los dos últimos post ¿recuerdan?).
¿Usando las dos aplicaciones en dos terminales diferentes qué vamos a ver?
En la terminal 1: aldo@mylinux:~/blogtest$ ./datawriter he escrito: nuevos datos 1 he escrito: nuevos datos 2 he escrito: nuevos datos 3 ^C En la terminal 2: aldo@mylinux:~/blogtest$ ./datareader me has escrito: nuevos datos 1 me has escrito: nuevos datos 2 me has escrito: nuevos datos 3Para enviar los loop a dormir he utilizado la función mySleep(), que es una nuestra vieja conocida: se puede insertar en una libreria separada o en la misma libreria libmmap (yo he utilizado un file separado mysleep.c con su header-file mysleep.h que solo contiene el prototipo). En este simple ejemplo, las dos aplicaciones que se comunican pueden detenerse usando CTRL-C, y (cuando vais a usar la libreria) podrais verificar que iniciando/detenendo/reiniciando ambas aplicaciones, en cualquier orden, siempre se vuelven a sincronizar sin problemas.
Por hoy hemos terminado. Esperando la segunda parte, podríais intentar imaginar cómo será la implementación de la libreria que os presentaré... pero llega la Navidad e imagino (y espero) que tengais cosas más interesantes en qué pensar en este período ...
¡Hasta el próximo post!
No hay comentarios:
Publicar un comentario