Discussion :

[loopiote]

Amis du jour bonjour, amis du soir bonsoir,

Mon problème est simple, mais pourtant impossible de le résoudre toute seule :

Est-il possible de passer en paramètre de la fonction signal un handler situé dans un autre fichier
( les appels à signal() et kill() dans un .c dédié au processus père et le handler() dans un autre .c contenant le code du/des fils) ?

A priori cela me parait simple, on le fait bien pour des appels de fonctions "normales", mais j'ai essayé en faisant des .h, des includes, mais je me fait insulter par le compilateur.

Je remercie d'avance quiconque pourra m'éclairer.

[Obsidian]

Bonsoir,

Est-il possible de passer en paramètre de la fonction signal un handler situé dans un autre fichier ( les appels à signal() et kill() dans un .c dédié au processus père et le handler() dans un autre .c contenant le code du/des fils) ?

Oui, il est tout-à-fait possible de faire de la compilation séparée et écrire tes handlers dans un fichier *.c dédié, si tu le souhaites, surtout si tu comptes reprendre ce fichier dans d'autres projets à l'avenir.

Par contre, il n'est pas possible d'utiliser les routines d'un autre processus ! Ils ne sont même pas censés se voir du tout, sauf artifices comme la mémoire partagée, ou autres.

Il est en revanche possible, et c'est heureux, de faire du code qui soit commun aux deux processus. C'est le principe de la « bibliothèque » (library, en américain), qu'elle soit statique ou partagée dynamiquement. Du point de vue de chaque processus, le code de cette bibliothèque est considéré comme du code leur appartenant, mais au niveau du système, ce code (dans le cas d'une bibliothèque dynamique) n'apparaît qu'à un seul endroit en mémoire.

[loopiote]

Merci pour cette réponse.
Je ne suis malheureusement pas encore débloquée. Je sais maintenant que c'est possible. Bien.

J'ai un fichier arbitre.c où sont crées des processus fils. Leur code a eux est placé dans un autre fichier joueur.c .
Mon arbitre dit au début : signal(SIGINT, handler) puis fait un kill(<fils>,SIGINT)
Je met la fonction handler dans joueur.c
Ensuite pour lier les deux c'est la galère... J'ai essayé de faire un joueur.h puis de faire un include dans arbitre.c, mais (est-ce à cause de mon makefile?) la fonction handler n'est pas reconnue par l'arbitre :
(.text+0x4a): undefined reference to handler

Pourriez vous m'indiquer comment faire s'il vous plait ?
C'est désespérant...

[Obsidian]

Merci pour cette réponse.
Je ne suis malheureusement pas encore débloquée. Je sais maintenant que c'est possible. Bien.

Oui, en fait, j'ai compliqué pour rien puisque dans le cas de processus père et fils, les codes sont identiques au moment de la mytose. Enfin, si c'est bien fork() que tu utilises.

J'ai un fichier arbitre.c où sont crées des processus fils. Leur code a eux est placé dans un autre fichier joueur.c

Toute la question est : comment crées-tu tes processus fils ? Si c'est avec fork(), ça passe. Si c'est avec exec() sur un fichier exécutable, alors il s'agit de deux processus qui n'ont absolument rien à voir entre eux, à part un lien de filiation qui fera que le fils mourra avec son père, à moins de s'émanciper entre temps.

Mon arbitre dit au début : signal(SIGINT, handler) puis fait un kill(<fils>,SIGINT)
Je met la fonction handler dans joueur.c
Ensuite pour lier les deux c'est la galère... J'ai essayé de faire un joueur.h puis de faire un include dans arbitre.c, mais (est-ce à cause de mon makefile?) la fonction handler n'est pas reconnue par l'arbitre :

(.text+0x4a): undefined reference to handler

Oui. C'est du C élémentaire. Ton fichier « *.h » va contenir les prototypes des fonctions, et éventuellement les variables déclarées dans d'autres fichiers mais visibles par un code donné, avec « extern ». Ce fichier définit les interfaces, c'est-à-dire les manières d'utiliser ces fonctions. Ceci va permettre de compiler un code en laissant des « blancs » qui seront comblés à l'édition des liens.

Tu peux comparer cela à la fabrication d'un avion : l'appareil entier est généralement conçu et fabriqué par un même atelier, sauf le moteur qui, lui, est produit par un motoriste spécialisé. Celui-ci va quand même te filer les spécifications dans un petit cahier (ici, ton *.h) qui va te permettre de prévoir les trous, les commandes, l'arrivée d'essence, etc. aux bons endroits même si tu ne dispose pas encore du moteur. Ensuite, quand les deux parties sortent de leurs usines respectives, il n'y a plus qu'à les assembler pour que ton avion soit complet.

D'où ton message d'erreur : tu as prévu de faire appel à des fonctions externes, ok. Mais au moment de finaliser l'exécutable, ces fonctions restent introuvables.

Pourriez vous m'indiquer comment faire s'il vous plait ?
C'est désespérant...

− Soit tu utilises l'option « -c » avec GCC pour produire des fichiers objet « *.o », et tu les lies ensuite avec « ld », ou directement avec GCC ;
− Soit tu compiles directement tous les fichiers *.c en une fois :

Code SHELL :

Sélectionner tout - Visualiser dans une fenêtre à part

$ gcc -o monprogramme joueur.c handler.c

Maintenant, attention : tu te sers des signaux pour faire quoi ? Une erreur très fréquente consiste à croire que les signaux UNIX (ceux émis par kill(), dont le nom devrait pourtant suffire à mettre la puce à l'oreille) servent à transmettre des données d'un processus à l'autre, ce qui n'est absolument pas le cas.

Voir ici, ici, ici et là.

Édit :

Mon arbitre dit au début : signal(SIGINT, handler) puis fait un kill(<fils>,SIGINT)

Si ton arbitre dit « signal(…) », ça veut dire qu'il définit la manière dont − lui − va gérer ces signaux si − lui − les reçoit. En aucune manière cela n'influera sur le fils qui fera comme ça lui chante, sauf s'il fait la même chose, bien sûr, ou si ce fils est créé avec un fork() depuis le processus arbitre et cela après que l'appel à signal() ait eu lieu.