Passer des parametres aux handler de signaux

C'est pourtant le cas si tu restes en C standard sans utiliser POSIX.

À moins d'invoquer explicitement le handler en appelant raise() depuis le code utilisateur, tu as énormément de restrictions car hors de ce cas, la fonction peut, selon la norme, être invoquée absolument à tout moment.
C'est la différence entre programmation événementielle et programmation interruptible...

Par contre, sous POSIX, ils se sont rendus compte que ça rendait la fonction pratiquement inutile et ont rajouté du code de synchronisation pour avoir une plus grande liberté dans le handler...

Citation:

---

Envoyé par souviron34

8O

Explique-toi, là, je comprend rien...

• Quelqu'un pose une question sur un signal-handler et les paramètres.
• Tu réponds que tout ce qu'il peut faire, c'est affecter une variable

Et ?? asynchronisme ?

---

Par définition, un signal est quelque chose d'asynchrone, généralement envoyé par le kernel au programme. Maintenant quand tu fais un raise() ou un abort() dans ton programme c'est bien toi qui déclenche l'envoi de ce signal, ça n'est donc plus asynchrone puisque tu peux assurément dire à quel moment tu recevras ce signal.

Citation:

---

Envoyé par Médinoc

C'est la différence entre programmation événementielle et programmation interruptible...

---

Merci, mais j'espère avoir saisi la notion, depuis 25 ans :?

Citation:

---

Envoyé par Médinoc

À moins d'invoquer explicitement le handler en appelant raise() depuis le code utilisateur, tu as énormément de restrictions car hors de ce cas, la fonction peut, selon la norme, être invoquée absolument à tout moment.
...
Par contre, sous POSIX, ils se sont rendus compte que ça rendait la fonction pratiquement inutile et ont rajouté du code de synchronisation pour avoir une plus grande liberté dans le handler...

---

Citation:

---

Envoyé par nicolas.sitbon

Par définition, un signal est quelque chose d'asynchrone, généralement envoyé par le kernel au programme. Maintenant quand tu fais un raise() ou un abort() dans ton programme c'est bien toi qui déclenche l'envoi de ce signal, ça n'est donc plus asynchrone puisque tu peux assurément dire à quel moment tu recevras ce signal.

---

oui et ?

je reviens encore :

un float divide, un SIGIO, un SIGTERM, SIGKILL, SIQUIT, SIGHUP, SIGALRM , c'est toi qui programme la routine qui fais le raise ou abort, ou bien tu mets dans ton programme :

Code:

---

signal ( SIGIO, MaFonction);

---

Et dans ce cas, ce n'est pas toi mais signal qui reçois.

Toi, ta fonction est appelée par signal. Et , mis à part le problème temporel, il n'y a aucune contrainte... Et la contrainte temporelle est uniquement pour ne pas éventuellement être interrompu au milieu de quelque chose..

Ce qui par exemple est totalement hors contexte si tu fais un timer qui se réveille une fois par heure et prends 10 minutes de calcul. Il n'y a aucune contre-indication..

De même, si tu fais un SIGIO, il n'y a aucune contre-indication à avoir une routine dans le handler qui va lire le socket, décoder un message, stocker dans des structures.. Heureusement, car sinon http et tous les browsers ne marcheraient pas... Sauf, que, pour qu'effectivement ça se passe bien, tu ne ré-armes qu'à la fin (puisque signal nécessite d'être réarmé).


Je répète donc encore une fois : dans une programmation interruptible, tant que la condition d'interruption n'est plus valide ET QUE tu n'es plus à lécoute (pas de signal réarmé), tu es totalement libre de ce que tu fais, du nombre de variable que tu affectes, etc etc...

Le conseil est évidemment de passer le moins de temps possible, mais, même pour un timer , ne serait-ce que le calcul du prochain appel , si l'intervalle n'est pas régulier, prend du temps.

Donc la seule ligne de conduite à avoir est : si possible faire le moins de choses possibles. Et ne ré-armer quune fois tout terminé.. C'est TOUT....

Regardez le code source de IE (ou Firefox si vous préferez), ou de Mosaic, ou de n'importe quel client-serveur, etc etc....

Mais tout ça n'est pas standard, mais POSIX. Donc, tu as moins de limitations, pour rendre la fonction utilisable.

Citation:

---

Envoyé par Médinoc

Mais tout ça n'est pas standard, mais POSIX. Donc, tu as moins de limitations, pour rendre la fonction utilisable.

---

8O

D'une part, nous sommes dans le forum POSIX, non ???

D'autre part, la portabilité est assurée par le flag -DPOSIX_SOURCE dnas n'importe quel gcc...

Pas "n'importe quel GCC" : MinGW possède quelques extensions POSIX, mais n'est pas suffisant pour faire tourner 100% des programmes POSIX sous Windows...

Pour le coup du forum POSIX, tu as raison sur ce point.

Citation:

---

Envoyé par Médinoc

Pas "n'importe quel GCC" : MinGW possède quelques extensions POSIX, mais n'est pas suffisant pour faire tourner 100% des programmes POSIX sous Windows...

---

;) depuis quand Windows nécessite un standard ?? :P


Voilà bien le fond du problème, je pense...

Ce qui est disponible sous toutes les versions d'Unix ou Linux, via des flags que ce soit BSD ou POSIX, ne l'est pas sous Windows... :aie:

Et donc on érige des restrictions d'un OS comme standards... :?

Je n'ai JAMAIS parlé de Windows comme d'un standard ici.

Et il n'y a pas que Windows qui est compatible C90 et pas POSIX: Il y a des systêmes embarqués aussi... (sans compter les systèmes embarqués qui ne sont pas standard C, comme certaines calculatrices).

eh cool 8-) je te charriais :P

Je suis d'accord, mais c'est donc en sens inverse qu'il faut faire la démonstration et l'exposé, par rapport à ce que toi et Nicolas avez dit :

Citation:

---

Pour tout système autre que Windows et quelques OS embarqués, il n'y a pas de problèmes. Par contre, pour Windows et certains OS embarqués, on est restrient par ceci et cela...

---

Car sinon on induit en erreur les gens...

(et encore une fois pour s'en convaincre il suffit de regarder les centaines de milliers de programmes existants)

:D


PS: j'ai fait tourner les mêmes signaux handlers lourds (plusieurs dizaines de variables, d'allocations, de calculs, des centaines de lignes de code, etc..) depuis 1994 sur des Sun, des HPUX, des Silicon, des PCs avec linux,.. et je n'ai jamais eu aucun problème.. Sauf effectivement quand j'ai voulu utiliser cygwin..

Citation:

---

Envoyé par souviron34

Pour tout système autre que Windows et quelques OS embarqués

---

Pourquoi ne pas appeler les standards par leur nom et dire "Pour tout système POSIX" ?

Citation:

---

Envoyé par souviron34

PS: j'ai fait tourner les mêmes signaux handlers lourds (plusieurs dizaines de variables, d'allocations, de calculs, des centaines de lignes de code, etc..) depuis 1994 sur des Sun, des HPUX, des Silicon, des PCs avec linux,.. et je n'ai jamais eu aucun problème.. Sauf effectivement quand j'ai voulu utiliser cygwin..

---

C'est ce qu'on appelle des comportements indéterminés, ça peut marcher comme ça peut planter, mais ça ne démontre qu'une chose, c'est que tu ne maîtrise absolument pas les signaux. Medinoc même sous POSIX, il y a des restrictions, seules quelques fonctions de plus sont dispos pour un gestionnaire mais ça s'arrête là. Le constat n'est pas brillant : même en citant la norme, vous n'admettez pas la réalité, qui plus est on apprend que du code comme ça est en production...

Pour info voici les modifs de POSIX :

Citation:

---

If the signal occurs other than as the result of calling abort(), raise(), [CX] [Option Start] kill(), pthread_kill(), or sigqueue(), [Option End] the behavior is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or if the signal handler calls any function in the standard library other than one of the functions listed in Signal Concepts. Furthermore, if such a call fails, the value of errno is unspecified.

---

et dans Signal concept on trouve cette liste de fonctions :

Citation:

---

The following table defines a set of functions that shall be either reentrant or non-interruptible by signals and shall be async-signal-safe. Therefore applications may invoke them, without restriction, from signal-catching functions:


_Exit()
_exit()
abort()
accept()
access()
aio_error()
aio_return()
aio_suspend()
alarm()
bind()
cfgetispeed()
cfgetospeed()
cfsetispeed()
cfsetospeed()
chdir()
chmod()
chown()
clock_gettime()
close()
connect()
creat()
dup()
dup2()
execle()
execve()
fchmod()
fchown()
fcntl()
fdatasync()
fork()




fpathconf()
fstat()
fsync()
ftruncate()
getegid()
geteuid()
getgid()
getgroups()
getpeername()
getpgrp()
getpid()
getppid()
getsockname()
getsockopt()
getuid()
kill()
link()
listen()
lseek()
lstat()
mkdir()
mkfifo()
open()
pathconf()
pause()
pipe()
poll()
posix_trace_event()
pselect()
raise()




read()
readlink()
recv()
recvfrom()
recvmsg()
rename()
rmdir()
select()
sem_post()
send()
sendmsg()
sendto()
setgid()
setpgid()
setsid()
setsockopt()
setuid()
shutdown()
sigaction()
sigaddset()
sigdelset()
sigemptyset()
sigfillset()
sigismember()
sleep()
signal()
sigpause()
sigpending()
sigprocmask()
sigqueue()




sigset()
sigsuspend()
sockatmark()
socket()
socketpair()
stat()
symlink()
sysconf()
tcdrain()
tcflow()
tcflush()
tcgetattr()
tcgetpgrp()
tcsendbreak()
tcsetattr()
tcsetpgrp()
time()
timer_getoverrun()
timer_gettime()
timer_settime()
times()
umask()
uname()
unlink()
utime()
wait()
waitpid()
write()

---

inquiétant tout ça...

Citation:

---

Envoyé par nicolas.sitbon

inquiétant tout ça...

---

8O

pouquoi ça ??

Et au vu de ta liste de fonctions et de ce qu'il est précisé :

Citation:

---

Therefore applications may invoke them, without restriction, from signal-catching functions:

---

c'est bien ce que je disais :mrgreen:



Ce ne sont donc en rien des comportements indéterminés, mais parfaitement déterminés... et en désaccord total avec ce que tu citais au début ;)

Citation:

---

Envoyé par souviron34

8O

pouquoi ça ??

Et au vu de ta liste de fonctions et de ce qu'il est précisé :




c'est bien ce que je disais :mrgreen:

---

Parce que si tu utilises une fonction qui n'est pas dans cette liste ou bien que tu modifies un objet statique qui n'est pas de type "volatile sig_atomic_t", tu as un comportement indéterminé, rien que ça.

Citation:

---

Envoyé par Médinoc

Pourquoi ne pas appeler les standards par leur nom et dire "Pour tout système POSIX" ?

---

parce que c'est pareil avec BSD, et SysV, et SVR ...

;)

ce qui forme la majeure partie des ordis hors PCs.

Citation:

---

Envoyé par nicolas.sitbon

Parce que si tu utilises une fonction qui n'est pas dans cette liste ou bien que tu modifies un objet statique qui n'est pas de type "volatile sig_atomic_t", tu as un comportement indéterminé, rien que ça.

---

euh.. Je crois qu'il y a là quelque chose d'étrange...

Pratiquement aucun des paramètres des fonctions citées n'est du type cité :P

Exemples :

• int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen);
• int lstat(const char *file_name, struct stat *buf);

D'autre part, cela réfère à

Citation:

---

any function in the standard library other than one of the functions

---

ce qui ne concerne en rien tes fonctions...

Citation:

---

Envoyé par souviron34

parce que c'est pareil avec BSD, et SysV, et SVR

---

Mais tous ces systèmes ne sont-ils pas justement réunis sous la norme POSIX ou la Single Unix Specification ?

Citation:

---

Envoyé par souviron34

ce qui ne concerne en rien tes fonctions...

---

Mais ça les concerne si elles appellent elle-même des fonctions de la bibliothèque standard.
Ou plus simplement, toute fonction non-réentrante ou non async-signal-safe.

Pour les types, ça semble restreint aux variable à stockage statique (vars globales, quoi). Cette norme ne semble rien dire sur les variables dans le tas...

Citation:

---

Envoyé par Médinoc

Mais tous ces systèmes ne sont-ils pas justement réunis sous la norme POSIX ou la Single Unix Specification ?

---

pour la Single Unix Spec je ne sais pas, mais pour le reste, bien sûr que non...

Sinon il n'y aurait pas "conforme à POSIX", "à BSD", "à SysV"...

Ce sont des normes concurrentes, de plus en plus convergentes mais POSIX n'est pas BSD, ou autres... (voir les flags de compils sous gcc)..

Citation:

---

Envoyé par souviron34

Pratiquement aucun des paramètres des fonctions citées n'est du type cité :P

Exemples :

int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen);

---

Pourquoi dont passer un objet statique (global au moins au fichier) en paramètre de fonctions, ce n'est pas très utile.

Citation:

---

Envoyé par souviron34

D'autre part, cela réfère à



ce qui ne concerne en rien tes fonctions...

---

Citation:

---

Otherwise, the application shall ensure that func points to a function to be called when that signal occurs. An invocation of such a function because of a signal, or (recursively) of any further functions called by that invocation (other than functions in the standard library), is called a "signal handler".

---

tu es têtu.

Citation:

---

Envoyé par souviron34

euh.. Je crois qu'il y a là quelque chose d'étrange...

Pratiquement aucun des paramètres des fonctions citées n'est du type cité :P

---

Le type volatile sig_atomic_t ne s'applique évidemment pas à un paramètre, ce qui n'aurait aucun sens, mais à une globale partagée entre l'application et le handler du signal (qui est une interruption véritable, donc, par définition, sans paramètres).