Problèmes de signaux

Bonjour tout le monde :)

Voila j'ai un petit souci en C et je me demandais si vous ne pourriez pas me mettre sur la voie ... Je dois faire deux processus : un serveur et un client .

Le client doit envoyer son pid sous forme binaire au serveur à l'aide des signaux SIGUSR1 et SIGUSR2 et attend la reception du signal SIGTERM du serveur pour se terminer proprement ...

Le serveur quant à lui reconstruit le pid du client et l'affiche, envoie un SIGTERM au client.

Le pid du serveur est envoyé en ligne de commande lorsque je lance le client ainsi on connait le pid du serveur dans le client.

J'ai beau rechercher comment envoyer le pid du client sous forme binaire au serveur sur le net mais je ne trouve pas ... Donc si vous pourriez me mettre sur la voie ce serait bien sympathique ..;

Merci d'avance

Pas trop complique.

Ton client fais des :

Code:

---

1 2	kill(`pid du serveur`, SIGUSR1); kill(`pid du serveur`, SIGUSR2);

---

Et ton serveur catch les signaux SIGUSR1 et SIGUSR2.
Apres tu choisi comment les interpreter, SIGUSR1 pour 0 et SIGUSR2 pour 1.

Merci pour la réponse :) Je vais tester ça ;)

Citation:

---

Envoyé par asnaeb

Le client doit envoyer son pid sous forme binaire au serveur à l'aide des signaux SIGUSR1 et SIGUSR2 et attend la reception du signal SIGTERM du serveur pour se terminer proprement ...

---

Arg ! C'est atroce ! J'espère franchement que ce n'est pas un énoncé scolaire, parce que si un signal UNIX est compté au nombre des quelques mécanismes qui permettent de communiquer entre deux processus, il ne servent absolument pas à transmettre des données directement.

On en parlait déjà ici, ici et là.

Peu etre atroce, mais a titre pedago, les signaux sont bien compris apres :p

Citation:

---

Envoyé par Damoun

Peu etre atroce, mais a titre pedago, les signaux sont bien compris apres :p

---

Non, même à titre pédagogique, il ne faut jamais se servir des signaux pour « faire du Morse ». Surtout pas à titre pédagogique en fait. Lis les discussions pointées dans mon précédent commentaire.

J'ai survole, et je sais au'il y a une grosse perte au niveau de la reception (liste chainee avec une taille definie...)

Bref je trouve que c'est un bon moyen d'apprendre au lieu de faire tout le temps des SIG_IGN.

Citation:

---

Envoyé par Damoun

Bref je trouve que c'est un bon moyen d'apprendre au lieu de faire tout le temps des SIG_IGN.

---

Quoi ? Je crois que tu confonds beaucoup de choses. Relis de manière plus approfondie.

Nan je ne confond pas

pour exemple

Code:

---

signal(SIGUSR1, SIG_IGN);

---

Qui ignore le signal (au cas ou hein)

Citation:

---

Envoyé par Damoun

Nan je ne confond pas

---

Si, tu confonds. :-) Où alors, tes notions ne sont pas encore assez solides.

Citation:

---

pour exemple

Code:

---

signal(SIGUSR1, SIG_IGN);

---

Qui ignore le signal (au cas ou hein)

---

• Si tu fais cela, tu ignores le signal SIGUSR1. Donc, tu ne peux plus les recevoir. Ce n'est cependant pas l'objet de la discussion : asnaeb cherche à transmettre son PID à un autre processus, et on explique qu'utiliser les signaux pour y parvenir est une très mauvaise idée. Il ne s'agit donc pas de bloquer les signaux entrants, mais de ne pas les émettre ;
• Il n'y a pas de « au cas où » dans le présent problème. SIGUSR1 et 2 sont déjà ignorés par défaut. Et s'ils ne l'étaient pas, c'est qu'il y aurait une très bonne raison à cela. Changer le handler du signal sans justification solide est donc une erreur de conception ;
• Encore une fois, les signaux UNIX ne servent pas à transmettre des données. Ils sont là pour faire face à un événement imprévu du système. Plus précisément, à quelque chose qui soit en dehors du périmètre du programme.

Dans ce dernier cas, si c'est imprévu, il n'y a que deux options possibles : soit c'est une erreur mineure qui n'empêche pas le programme de fonctionner, et dans ce cas-là, on ignore le signal puisqu'il n'y a rien à faire d'autre, soit c'est une erreur critique et là, on met fin au programme. En tout cas, par défaut.

Les événements systèmes qui nécessitent l'attention immédiate du programme sont donc peu nombreux : parmi eux, on compte la division par zéro, un tube brisé à l'initiative du correspondant ou parce que la ligne de transmission s'est effondrée, ou encore toutes les demandes d'arrêt du programme, envoyés notamment si le système entier est sur le point d'être éteint.

SIGUSRx, notamment, signifie sémantiquement « altération du système à l'initiative de l'utilisateur », et est donc envoyé par lui. C'est très utile, par exemple, pour relire un fichier de conf' si besoin, et ce, parce que le moment où l'utilisateur décidera de modifier ce fichier ne peut être connu à l'avance et que le logiciel qu'il utilisera pour ce faire sera indépendant de l'application qui utilise le fichier (en général, ce sera un éditeur de texte).

Ça veut dire également qu'utiliser SIGUSRx pour faire communiquer deux programmes, quels qu'ils soient, n'est pas un bon modèle non plus : d'abord parce que si le protocole de communication à travers ces signaux est défini à la conception du programme, rien n'empêche de le faire passer à travers un tube ordinaire, à la place. Ensuite, parce que ces signaux peuvent être envoyés par n'importe qui, à commencer par l'utilisateur.

En particulier, il existe une manière de faire assez répandue (et bien plus censée que d'envoyer des bits via SIGUSR1 ou 2) qui consiste à déclarer un segment de mémoire partagée, et à utiliser un signal pour prévenir l'autre processus que de nouvelles données sont disponibles. C'est un moindre mal, mais le signal ne devrait même pas être utilisé dans ce cas, à mon goût, car le recours aux signaux ne doit être qu'occasionnel, parce que n'importe qui peut en envoyer un, ce qui peut perturber le fonctionnement du programme, parce que ça ne permet d'envoyer qu'un seul type d'information, là où un bête tube ou socket permet la transmission d'un message structuré (avec identifiant de l'émetteur, etc.), et enfin parce que pour pouvoir utiliser les signaux, il faut que le processus récepteur transmette son PID à l'autre. Pour cela, il faut une voie de communication, que l'on peut alors utiliser directement pour transmettre les informations.

Non je ne confond pas, je parle de l'utilisation des signaux en general.

Ce n'est pas le sujet, son exo lui demande de communiquer avec des signaux, donc il n'y a pas a discuter dessus.

La solution a ete donnee, on est d'accord que ce n'est pas la facon dont communique un server/client en realite.

De plus ce n'est pas a terme, pour une production, cela reste dans le cadre d'apprentissage (des signaux).

Je suis d'accord sur le faite qu'un pipes est bien plus approprie.

Citation:

---

Envoyé par Damoun

Ce n'est pas le sujet, son exo lui demande de communiquer avec des signaux, donc il n'y a pas a discuter dessus.

---

Si, il y a clairement à discuter dessus, puisque cette entrée va rester référencée dans le forum un moment, et que n'est pas la première fois que le sujet revient. C'est, en outre, exactement l'objet de mon post numéro 4 :

Citation:

---

Envoyé par Obsidian

Arg ! C'est atroce ! J'espère franchement que ce n'est pas un énoncé scolaire, parce que si un signal UNIX est compté au nombre des quelques mécanismes qui permettent de communiquer entre deux processus, il ne servent absolument pas à transmettre des données directement.

---

Citation:

---

La solution a ete donnee, on est d'accord que ce n'est pas la facon dont communique un server/client en realite.

---

Dans ce cas, ce n'est pas un exemple à donner.

Citation:

---

De plus ce n'est pas a terme, pour une production, cela reste dans le cadre d'apprentissage (des signaux).

---

Non seulement cela n'apporte strictement rien d'un point de vue pédagogique, mais c'est la meilleure façon d'induire un novice en erreur. C'est l'exemple à fuir. Si, en plus, c'est en classe qu'on lui demande d'agir ainsi, c'est une raison de plus pour insister − ici − sur le fait que ce genre de hack ne doit jamais être utilisé.

Citation:

---

Envoyé par Obsidian

Non seulement cela n'apporte strictement rien d'un point de vue pédagogique, mais c'est la meilleure façon d'induire un novice en erreur. C'est l'exemple à fuir. Si, en plus, c'est en classe qu'on lui demande d'agir ainsi, c'est une raison de plus pour insister − ici − sur le fait que ce genre de hack ne doit jamais être utilisé.

---

Ce n'est pas mon avis, sa apporte forcement, puisque apres cette exo, il comprendras comment marche les signaux (les differentes fonction a utiliser, et aussi un peu sur les process).

Bref pour moi le sujet est resolu, asnaeb a demander de l'aide, je lui est repondu, comment faire (avec obligation d'utilise les signaux).

Citation:

---

Envoyé par Damoun

Ce n'est pas mon avis, sa apporte forcement, puisque apres cette exo, il comprendras comment marche les signaux (les differentes fonction a utiliser, et aussi un peu sur les process).

---

C'est ce qui nous distingue : ça n'apporte rien sur le fonctionnement réel des signaux, ni même sur la manière de les utiliser correctement. Par contre, cela donne d'entrée de mauvaises habitudes.

Citation:

---

Bref pour moi le sujet est resolu, asnaeb a demander de l'aide, je lui est repondu, comment faire (avec obligation d'utilise les signaux).

---

À dire vrai, même pour toi seul, tu ne devrais pas t'en satisfaire. Il vaut mieux un programme incomplet ou un problème à moitié résolu mais qui soit assis sur des bases solides, plutôt qu'un problème résolu à tâtons et considéré comme valide à la première exécution vérifiée, sans que l'on sache pourquoi. Nous apprécions ton aide, mais l'objectif de ce forum n'est pas de « faire du chiffre ».

Petite question d'ordre un peu plus personnel.

Les signaux temps-réel ne sont-ils pas plus orientés vers la transmission d'informations ?

- http://davmac.org/davpage/linux/rtsignals.html
- http://www.mnis.fr/ocera_support/rtos/x1215.html

Bonjour,

Citation:

---

Envoyé par BSans

Les signaux temps-réel ne sont-ils pas plus orientés vers la transmission d'informations ?

---

Non, c'est même pire, à mon avis. Les signaux temps réel sont faits pour garantir certaines priorités et un temps de transmission suffisamment rapide pour gérer des événements rapides, comme la gestion des timers haute résolution, comme précisé sur la page en question.

Ça veut dire qu'ils sont une charge encore plus contraignante pour le système, et ils ne sont toujours pas dédiés à la transmission de données, même si les signaux RT peuvent être accompagnés d'une petite quantité de données pour les spécialiser.

C'est vraiment une drôle d'idée de vouloir utiliser à tout prix les signaux UNIX pour faire du message passing. Je pense que la confusion provient du fait que, d'une part, on les classe dans les IPC au sens large et, d'autre part, que le terme « signal » est utilisé de manière assez vague en informatique pour désigner un certain nombres de concepts similaires mais différents. Les signaux de GTK, par exemple, n'ont rien à voir avec les signaux système UNIX.

Bonsoir tout le monde.

Un grand merci à vous deux déjà :D Je vais aller lire un peu tout les liens qui ont été postés. Eh oui c'était bien un énoncé qu'on m'a donné à l'école 8-)

Encore juste une petite question, qui n'a plus rien à voir avec les signaux cette fois-ci :), je me demandais si en qnx la fonction kbhit() existait? Car je voudrais boucler tant qu'un utilisateur n'a pas appuyé sur une touche ... Merci d'avance ;)

plusieurs solutions s'offrent à toi en fonction de ce que tu souhaite faire et de l'importance de tes descripteurs de fichiers par rapport à tes traitements.

Tu peux jouer sur la propriété de ton descripteur de fichier pour le rendre non bloquant (O_NONBLOCK ou O_NDELAY) et regarder de temps en temps si des données sont présentes.
http://www.linux-kheops.com/doc/man/...n2/open.2.html


Tu peux aussi jouer avec FD_SET et select ou poll.
http://linux.die.net/man/3/fd_set
http://linux.die.net/man/2/select_tut

Je ne comprend pas vraiment comment je pourrais arriver à arrêter une boucle en appuyant sur une touche avec un descripteur de fichier ou avec FD_SET, select ou poll :? Si tu peux m'éclairer ?

Désolé j'avais mal cerné ton besoin, je pensais que tu voulais faire des traitements en boucle en attendant que l'utilisateur se reveille et fasse quelque chose de son clavier.


si c'est juste attendre qu'il appuie sur une touche tu peux utiliser getchar ou read
http://linux.die.net/man/3/getchar

Merci mais en fait je recherche une fonction qui n'est pas bloquante en fait ... Je voudrais afficher continuellement l'état de capteurs. Et si on presse une touche on reviens dans un menu. Donc je crois que pour le getchar il attend qu'on entre un caractère, mais ce que je voudrais c'est qu'il ne reste pas bloqué sur cette instruction comme le fait kbhit() mais apparemment cette fonction n'est pas supporté par qnx ..

J'ai trouvé "tcischars" qui fait office de kbhit(). Je vais tester si cette fonction fait bien ce que je veux :)