Discussion :

[amira88]

Salut,
Est ce que lorsque je fais :

Code :

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

1
2
3
 
sigset_t set:
sigaddset(&set ,1000) :

j'ajoute l'écoute sur le signal 1000: donc je suis en attente du signale 1000.
Que permet de faire sigaddset(..) pour quelle raison on l'utilise.
J'ai trouvé quelle ajoute à l'ensemble set le signal signum,Mais c'est pas claire!!
Merci pour votre aide

[Obsidian]

Tout est là : sigsetopts.

Ce que tu as écrit est syntaxiquement correct, à ceci près que le C utilise le point-virgule « ; » comme séparateur et pas le deux-points « : ».

Il n'y a pas de signal 1000, sous Unix. Il n'y en a qu'une trentaine (sans compter les signaux spéciaux RTMIN et RTMAX) bien définis, et qui ont tous une signification propre. Contrairement à une idée un peu trop répandue, un signal Unix ne sert absolument pas à échanger des données. C'est une erreur fréquente car il est au nombre restreint des mécanismes permettant de communiquer avec un autre processus.

Dans le même esprit, on ne se met pas non plus « à l'écoute » d'un signal Unix à proprement parler. C'est un événement qui est déclenché par le système lorsque la situation change de telle manière que le processus ne peut poursuivre son déroulement normalement. Par exemple : la destruction d'un tube (parce que l'autre partie a « raccroché », une segfault, la destruction du processus père, la destruction d'un fils, ou l'interruption du processus à la demande de l'utilisateur avec Ctrl-C.

Un signal est donc « violent », dans le sens où il préempte le processus. Par défaut, cela ne se termine que de deux façons : soit ton processus est détruit (majorité des cas), soit le signal est ignoré (par exemple, si un fils meurt). Tu peux avoir la liste des signaux Unix depuis la ligne de commande en tapant kill -l. Tu peux ensuite définir si tu le souhaites un comportement personnalisé pour chaque signal, excepté SIGKILL (kill -9) et SIGSTOP.

Pour les sigsets en particulier, il est souvent utile de définir des paramètres sur plusieurs signaux à la fois, ne serait-ce que pour rendre l'opération atomique. Dans ce cas, on passe un « jeu de signaux » (sigset) plutôt qu'un numéro unique. Il faut alors commencer par déclarer un sigset, l'initialiser et le remplir avec les numéros des signaux qui nous intéressent. On passe ensuite ce sigset à la fonction en a besoin.

À noter que le contenu de ta variable « set » est indéfini par défaut. Comme tu ne sais pas comment est défini le type sigset_t, tu ne peux pas l'initialiser à la déclaration. Il faut donc utiliser d'abord sigemptyset() ou sigfillset(), car le résultat de ces deux fonctions est complètement indépendant de l'état précédent de « set ».

[amira88]

Tout est là : sigsetopts.

Ce que tu as écrit est syntaxiquement correct, à ceci près que le C utilise le point-virgule « ; » comme séparateur et pas le deux-points « : ».

Il n'y a pas de signal 1000, sous Unix. Il n'y en a qu'une trentaine (sans compter les signaux spéciaux RTMIN et RTMAX) bien définis, et qui ont tous une signification propre. Contrairement à une idée un peu trop répandue, un signal Unix ne sert absolument pas à échanger des données. C'est une erreur fréquente car il est au nombre restreint des mécanismes permettant de communiquer avec un autre processus.

Dans le même esprit, on ne se met pas non plus « à l'écoute » d'un signal Unix à proprement parler. C'est un événement qui est déclenché par le système lorsque la situation change de telle manière que le processus ne peut poursuivre son déroulement normalement. Par exemple : la destruction d'un tube (parce que l'autre partie a « raccroché », une segfault, la destruction du processus père, la destruction d'un fils, ou l'interruption du processus à la demande de l'utilisateur avec Ctrl-C.

Un signal est donc « violent », dans le sens où il préempte le processus. Par défaut, cela ne se termine que de deux façons : soit ton processus est détruit (majorité des cas), soit le signal est ignoré (par exemple, si un fils meurt). Tu peux avoir la liste des signaux Unix depuis la ligne de commande en tapant kill -l. Tu peux ensuite définir si tu le souhaites un comportement personnalisé pour chaque signal, excepté SIGKILL (kill -9) et SIGSTOP.

Pour les sigsets en particulier, il est souvent utile de définir des paramètres sur plusieurs signaux à la fois, ne serait-ce que pour rendre l'opération atomique. Dans ce cas, on passe un « jeu de signaux » (sigset) plutôt qu'un numéro unique. Il faut alors commencer par déclarer un sigset, l'initialiser et le remplir avec les numéros des signaux qui nous intéressent. On passe ensuite ce sigset à la fonction en a besoin.

À noter que le contenu de ta variable « set » est indéfini par défaut. Comme tu ne sais pas comment est défini le type sigset_t, tu ne peux pas l'initialiser à la déclaration. Il faut donc utiliser d'abord sigemptyset() ou sigfillset(), car le résultat de ces deux fonctions est complètement indépendant de l'état précédent de « set ».

Bonjour,
Merci pour votre réponse donc set est un ensemble de signaux ,
par exemple Si je veux interrompre un processus par un signal je dois l'ajouter a set avec sigaddset(...), sinon le processus ne peut pes connaitre le signal!!
Merci encore

[Obsidian]

Bonjour, Merci pour votre réponse donc set est un ensemble de signaux

Sémantiquement, oui. Plus précisément, c'est un ensemble de numéros qui correspondent aux signaux qui t'intéressent.

par exemple Si je veux interrompre un processus par un signal je dois l'ajouter a set avec sigaddset(...),

Non. Ce n'est pas tout-à-fait cela.

Tu peux tout-à-fait gérer le comportement du processus sur réception d'un signal individuel avec signal(), par exemple. Les fonctions sigaddset() et consors ne sont que des fonctions de gestion d'une liste de signaux. À toi ensuite de passer cette liste aux fonctions qui sont capables de l'exploiter, telles que sigprocmask().

Comme dit plus haut, le principal intérêt d'une gestion d'ensembles de signaux est de pouvoir faire des opérations atomiques.

sinon le processus ne peut pes connaitre le signal!! Merci encore

Si. Les signaux sont en quelque sorte des alertes système. Ils sont tous définis à l'avance, on ne « crée » pas de niveau signal, et chacun d'un a un comportement par défaut dans chaque processus. Lorsque ton application reçoit un signal, il se peut qu'elle l'ignore, mais elle l'aura bien reçu. La plupart du temps, d'ailleurs, ce signal provoquera sa fin.