Discussion :

[eponyme]

Bonjour à tous,
j'ai un programme qui charge des fichiers .so dynamiquement, en cours d'exécution (avec dlopen() ).
Si, alors qu'un .so est chargé, je le modifie (pour mise à jour), des que mon programme veut accéder à une fonction qui etait exportée par ce .so, il plante.
Une solution (peu propre) pourrait etre qu'avant un dlopen() , je fasse une copie du fichier par programme dans un répertoire de travail, et que je supprime cette copie apres un dlclose().

Si le nombre de .so est conséquent, ca pourrait devenir lourd.

J'aimerais donc savoir s'il serait possible que soit le programme détecte une modification du .so, ou qu'il soit prévenu de l'extérieur (avec un signal) afin que je puisse le protéger du plantage ?

On m'a parlé de mmap, mais je n'ai pas vraiment compris le principe.


Merci d'avance,

eponyme

[corrector]

j'ai un programme qui charge des fichiers .so dynamiquement, en cours d'exécution (avec dlopen() ).
Si, alors qu'un .so est chargé, je le modifie (pour mise à jour), des que mon programme veut accéder à une fonction qui etait exportée par ce .so, il plante.

Ben oui!

Il ne faut jamais modifier un fichier en cours d'exécution!

Si tu as une MàJ à faire, tu "déconnectes" (unlink) les fichiers qui peuvent être en cours d'utilisation, et tu créé le nouveau à la place.

(Ce que ld devrait faire, AMA.)

[eponyme]

Merci pour ta réponse.
J'ai choisi un systeme avec "signal()" qui lorsqu'il est recu, le programme décharge ses .so, et lorsqu'il est recu une seconde fois, les recharge.

eponyme

[corrector]

Merci pour ta réponse.

Je t'en prie.

J'ai choisi un systeme avec "signal()" qui lorsqu'il est recu, le programme décharge ses .so, et lorsqu'il est recu une seconde fois, les recharge.

Je suppose que tu sais ce qui est permis ou pas dans un gestionnaire de signal.

[eponyme]

Je ne sais pas vraiment.
J'utilise le signal "SIGUSER1", qui "si j'ai bien compris", est avec SIGUSER2 un signal dont l'interprétation est laissée libre par l'utilisateur. Dans certains programme il est utilisé pour affihcer des infos. Je me suis donc dis que moi je pouvais l'utiliser pour prevenir le programme depuis l'extérieur qu'il fallait decharger les .so pour une mise à jour.

eponyme

[corrector]

Je ne sais pas vraiment.
J'utilise le signal "SIGUSER1", qui "si j'ai bien compris", est avec SIGUSER2 un signal dont l'interprétation est laissée libre par l'utilisateur. Dans certains programme il est utilisé pour affihcer des infos. Je me suis donc dis que moi je pouvais l'utiliser pour prevenir le programme depuis l'extérieur qu'il fallait decharger les .so pour une mise à jour.

Oui, les SIGUSR* sont des signaux utilisables de façon "discrétionnaire" par le programme.

Mais je parle de ce que tu fais à l'intérieur du gestionnaire de signal.

D'après ta réponse : si tu n'es pas sûr, à mon avis tu ne devrais pas utiliser un gestionnaire de signal. Je pense même qu'une personne qui a besoin de venir chercher de l'aide ici ne devrais pas s'y aventurer.

D'autre part, il y a un autre problème : comment le programme qui envoie le signal sait que le programme a reçu, et traité le signal?

(Pour moi, le fait même de se retrouver à utiliser un signal sans sémantique intrinsèque comme SIGUSR* est une absurdité, à de très rares exceptions.)