Utilisation des signaux.

Version imprimable

Bonjour,

je recherche de l'aide sur les signaux (sur FreeBSD et si possible pour un code en multi platforme Sun et Linux).

J'ai trouve ce code sur internet (merci google), et j'aimerais quelques explications svp.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 #include <stdio.h> #include <signal.h> #include <unistd.h> void handler(int); int nsig[NSIG]; void handler(int s) { printf("Signal %d recu %d fois\n", s, ++nsig[s]); } int main(void) { int s; for (s = 1; s < NSIG; s++) { if (signal(s, handler) == SIG_ERR) fprintf(stdout, "Je ne peux pas attraper signal no %d\n", s); nsig[s] = 0; } while (1) pause(); }
Je suis en train de code un interpreteur de comande (minishell :D) et j'aimerais savoir:

_ Comment recuperer un signal depuis un read de 0 (si c'est possible)
_ Comment recuperer le signal d'une touche ou d'un ensemble de touche.

Merci :)

13/02/2009, 11h00
tonton fred

Salut,

Le programme que tu as poste boucle sur les signaux du systeme (de 1 a NSIG) et essaye de les intercepter (signal(3)) et d'executer handler. Si signal(3) echoue (SIG_ERR), l'interception a echoue.

Ce que tu sembles vouloir faire ne necessite pas de signaux: les signaux sont de la communication entre processus via kill(2). par contre tu peux tres bien faire un processus separe qui gere la lecture / le clavier et qui envoie un signal au processus maitre qui y reagit.
13/02/2009, 12h20
matafan

Citation:

Envoyé par blazed

_ Comment recuperer un signal depuis un read de 0 (si c'est possible)

Un read de 0 ne génère pas de signal.

Citation:

Envoyé par blazed

_ Comment recuperer le signal d'une touche ou d'un ensemble de touche.

L'appuis d'une touche ne génère pas de signal.
14/02/2009, 19h28
blazed

Citation:

Envoyé par matafan

Un read de 0 ne génère pas de signal.

Pourtant read(2) de 0 reagit au signal "ctrl+d"
dans mon interpreteur, il me reaffiche mon prompt.

Pourriez vous me conseiller des mans a lire? (signal, kill...).

Merci :)
14/02/2009, 20h02
tonton fred

Ce n'est pas read qui reagit mais le terminal auquel ton programme est associe. Et ctrl-d n'est pas un signal, c'est le "caractere" (a defaut d'un meilleur nom) EOF. De la meme maniere, ctrl-c, ctrl-\, ctrl-z ne sont pas des signaux, ce sont des "caracteres" auquel le terminal reagit.
Tu pourrais lire man signal, man sigaction, man kill etc... Mais je pense que ce qui t'apporterait le plus ce serait de definir ce que tu veux faire ;)
14/02/2009, 20h16
Obsidian
Citation:

Envoyé par blazed

Pourtant read(2) de 0 reagit au signal "ctrl+d"
dans mon interpreteur, il me reaffiche mon prompt. Pourriez vous me conseiller des mans a lire? (signal, kill...). Merci :)

Bonjour,

Tu confonds, comme un certain nombre de personnes - y compris un de mes anciens profs - les signaux UNIX et le message passing en général. Bien que les signaux fassent officiellement partie des IPC au sens large (ils font effectivement partie du cercle restreint des ressources qui permettent de transmettre une info d'un processus à un autre), il ne servent absolument pas à ça.

Sous Unix, donc, les signaux sont ce qui est envoyé par « kill ». Tu peux en obtenir la liste avec kill -l. Ce sont des mécanismes du noyau, qui préemptent le processus peu importe l'endroit où il en est, et qui servent principalement à faire face à l'imprévu, provoquant généralement sa mort, ou étant ignorés. En gros, les signaux concernent :
- les erreurs d'exécution telles que segfault, division par zéro et autres exceptions ;
- la suspension temporaire du programme (à l'initiative de l'utilisateur ou parce qu'écriture dans un console en tant que tâche de fond, etc.) ;
- la terminaison demandée du programme, forcée ou non ;
- l'état du système (préparation à l'extinction, onduleur qui signale une coupure, etc.)
- les événements qui concernent les ressources du noyau comme l'écriture dans un pipe quand il n'y a plus de lecteur, l'échéance d'un timer, un périphérique qui demande d'urgence l'attention du processus, etc.
Un signal est donc un événement relativement violent. Il entre en mode noyau et préempte le processus. D'autre part, il est comparable à une IRQ et, en ce sens, il sert à attirer l'attention du processus qui, ensuite, doit aller chercher les infos dont il a besoin. Un signal ne sert surtout pas à transmettre une donnée.

Cela dit, « signal » est un terme général avant de s'appliquer aux signaux UNIX. On retrouve ce terme dans GTK, par exemple. Les signaux GTK n'ont rien à voir avec les signaux UNIX.

En ce qui concerne Ctrl-D, ce sont deux choses différentes. On en parlait déjà ici. Ctrl-D émet le code ASCII « 04 », qui est interprété par le terminal local comme « End Of Transmission ». Le terminal envoie alors le contenu du buffer. Si ce buffer est vide, il envoie donc une chaîne de longueur nulle, ce qui est interprété par read() ... comme une fin de transmission, et une refermeture du tube par l'homologue. À aucun moment, le noyau n'a eu à intervenir d'une manière particulière.
16/02/2009, 10h53
blazed

Merci beaucoup d'avoir pris le temps de m'expliquer.

Effectivement, j'etais partis avec l'idee qu'un signal ete une trasmition d'ordre et de plus que j'emetais des signaux par le biais du clavier.
Ceci fixer, je vais revoir mes plans.

Merci.