2010-07-01 10 views
7

Se menciona en ftok() manual de¿Qué archivo debo pasar como argumento de nombre de ruta de ftok()

key_t ftok(const char *pathname, int proj_id); 

El ftok() función utiliza la identidad del archivo llamado por el nombre de ruta dada (que debe consulte un archivo existente y accesible) ...

Estoy confundido acerca de const char *pathname.

¿Cuál sería la mejor práctica para ello? En mi sistema actual puedo pasar "/home/Andrew/anyfile" pero no es posible que otros sistemas, en los que mi programa deba funcionar, tengan este archivo.

¿Qué tal si uso "/etc/hosts/" o "/etc/inittab" porque estoy seguro de que todos estos sistemas tendrán estos dos archivos? ¿Es una buena idea? ¿Puede causar algún problema?

No deseo pedirle al usuario que ingrese el nombre del archivo en el momento de la ejecución ni pasar el nombre del archivo como argumento de la línea de comando.

¿Hay alguna otra forma diferente y mejor de decidir pathname?
¿Cuál es la mejor y más confiable?

Gracias por su tiempo.

+0

¿Mejor manera para qué? Confiable para qué? - Tal vez es mejor describir una tarea para la cual se supone que se usa ftok. – pmod

+0

@Pmod: en realidad, necesito una cola para que mis dos programas puedan comunicarse entre sí. Lo que realmente me ha confundido es ese archivo que debo pasar a ftok() que siempre estará presente. [Esta respuesta] (http://stackoverflow.com/questions/3155291/which-file-should-i-pass-as-pathname-argument-of-ftok/3155312#3155312) dice que está bien pasar ''/etc''. Si es así, ¿por qué las personas pasan otros archivos? ¿No es fácil y mejor pasar uno de los archivos del sistema? –

+0

Cuando tuvimos la tarea similar (comunicación organizada entre dos programas en Linux con la ayuda de la cola de mensajes) - usamos el archivo. El primer programa (que es como servidor - siempre en ejecución) crea un archivo con id de mensaje, luego el segundo (programa de usuario) lee el id. De mensaje de ese archivo y tiene acceso a la cola. – pmod

Respuesta

12

Bueno, generalmente usaría un archivo asociado con la aplicación en sí.

Por ejemplo, teníamos una aplicación que cargaba un archivo de configuración en la memoria compartida (de una manera analizada de manera eficiente, piense en un archivo XML que se ha convertido en estructuras en memoria con punteros rápidos, etc.) creó el segmento de memoria compartida del ftok derivado del archivo de configuración mismo.

En el peor de los casos, si no tiene archivos de configuración para su aplicación, intente usar el ejecutable. Puede estar bastante seguro de que existe en algún lugar del sistema (ya que lo está ejecutando).

Tampoco está restringido a los archivos, puede usar /etc sí mismo o /tmp o incluso / si es necesario.

Digo "si debe" porque es un poco peligroso. La llamada ftok le dará una clave única basada en su especificación de archivo y su ID. Si utiliza su propio archivo como /etc/andrew.conf, puede estar razonablemente seguro de que no obtendrá un choque con ninguna otra ftok -clave devuelta.

Sin embargo, si usted y todos los demás deciden usar /tmp como parte de la especificación del archivo, el único diferenciador es la ID. Por lo tanto, es mucho más fácil tener una colisión con otras teclas.

Lo que siempre he hecho es usar la especificación del archivo como un valor verdaderamente único para mi aplicación y luego simplemente usar la identificación para la cosa en particular que quiero crear.

Por lo tanto, si necesito 27 semáforos y 15 bloques de memoria compartida, que todo uso /etc/pax.conf como la especificación de archivo y los IDs de 1 a 42 (y mi solicitud sabe qué ID se relaciona con qué objeto).

+0

"puede usar' '/ etc'' en sí mismo o' '/ tmp'' o incluso' '' 'si es necesario". ¿Es una mala idea? Si está permitido, ¿por qué tu gente no lo usó en tu aplicación? Esto me confunde. Cuando podemos usar ''/etc/hosts'' o cualquier archivo de sistema que esté siempre presente, ¿por qué tenemos que buscar otras formas? Explíquelo. Gracias –

+1

@andrew: Ver actualización. – paxdiablo

+0

+1 Gracias paxdiablo –

1

usted puede construir dinámicamente un char * para un camino basado en un archivo de configuración, o un parámetro de línea de comandos, etc.

que sólo tiene que pasar char * a la función.

2

Probablemente lo mejor es usar argv [0] de uno de tus ejecutables. La página del manual dice

The resulting value is the same for all pathnames that name the same file, ... 

por lo que debe ser seguro, incluso si el ejecutable se llama a veces a través de un enlace simbólico o menos.

+0

¡Claro! Pero, ¿cómo lo sabrá el otro programa al respecto? Pathname y proj_id deben ser iguales en ambos programas para que ftok() genere la misma clave. Uno de ellos usa argv [0] entonces, ¿cómo otros lo sabrán? Amablemente elaborado. –

+0

La idea de ftok es que los dos programas comparten el conocimiento común. Yo supondría que conocen los nombres ejecutables de los demás. Luego tiene la clave adicional que ayuda a distinguir varias sesiones de la misma aplicación. En cualquier caso, debe compartir ese conocimiento común en el inicio, por ejemplo, con una variable de entorno más o menos. –

Cuestiones relacionadas