@nicolas :
je te répète : quel programme C autre que pour le Kernel appelle directement raise ou abort ????????????
Version imprimable
@nicolas :
je te répète : quel programme C autre que pour le Kernel appelle directement raise ou abort ????????????
est-ce que, quand vous programmez un signal handler, vous appelez signal dans le signal-handler ????
Réponse : non...
c'est bien, tu cites justement les restrictions auquelles fait allusion Medinoc.Citation:
Envoyé par souviron34
Oui pour réarmer éventuellement le signal.Citation:
Envoyé par souviron34
lis plus bas ;)Citation:
Envoyé par nicolas.sitbon
Cette partie de doc est faite pour le Kernel, pas pour la programmation usuelle.
Bien évidemment, puisque les fonctions raise et abort existent, tu peux t'en servir, et ce paragrpahe te donne les conditions d'utilisation.
Mais cela n'a rien à voir avec la notion de signal-handler communément utilisée en C, et en particulier via la fonction signal...
super...Citation:
Envoyé par nicolas.sitbon
Donc à ce compte-là, et vu que tu n'as le droit de rien faire d'autre qu'affecter une variable, tu fais un sleep et une fois par seconde par exemple tu changes ta varaible... ;)
Programme super intéressant ... :aie:
je reprend l'exemple des sockets...
Tu reçois quelque chose... Ton signal-handler est réveillé car tu as fais un signal (SIGIO, handler);
Tu ne vas pas lire ce qu'il y a dessus ???
Ce passage de la norme m'a échappé ainsi qu'à ceux que j'ai cité apparemment, peux tu nous donner l'extrait s'il te plaît?Citation:
Envoyé par souviron34
Je vais finir par me lasser...Citation:
Envoyé par nicolas.sitbon
Regarde tous les exemples (ici-même et ailleurs) de clients-serveurs, de timers, et autres....
Montre m'en un qui fait appel à raise, ou à abort...
Si tu parles de sockets, ça n'est plus du C mais du POSIX, et à ce compte là, comme je l'ai dis plus haut, il y a plus de fonctions utilisables, dont la fonction read().Citation:
Envoyé par souviron34
8OCitation:
Envoyé par nicolas.sitbon
ioctl, fnctl, etc, c'est pas du C ??
signal, c'est pas du C ?
ça n'est pas un argument et les références que j'ai cité sont assez parlantes.Citation:
Envoyé par souviron34
signal est C, le reste est POSIX.Citation:
Envoyé par souviron34
ah pardon !!Citation:
Envoyé par nicolas.sitbon
A quelqu'un qui pose une question sur un signal-handler, tu lui réponds qu'il n'a le droit qu'à une varaible de telle classe et que si il a levé raise ou abort...
Mon point me semble un bon argument, au contraire, au vu de ta réponse, qui, elle n'est valable que dans certains cas non généralement utilisés...
Non justement, seulement s'il n'a pas appelé raise() ou abort().Citation:
Envoyé par souviron34
grrrr....Citation:
Envoyé par nicolas.sitbon
Encore une fois (et tu appuies encore la validité de mon argument ci-dessus), montre moi un code applicatif où on fait appel à raise ou à abort (pour s'affranchir donc de cette contrainte, si je te suis)..
ou, réciproquement, un code applicatif où on ne fait pas appel à raise ou à abort, et qui est 100% restreint à ta condition...
On ne le fais pas pour s'affranchir des ces contraintes, mais c'est le fais de provoquer un signal par l'appel à ces fonctions, qui retire cette notion d'asynchronisme et qui par conséquent n'impose pas de restriction.Citation:
Envoyé par souviron34
Je n'ai pas le droit de mettre en ligne mes codes sources car ils restent la propriété de ma boîte, en revanche dans le lien que j'ai donné par exemple (celui du CERT) tu as de bons exemples.Citation:
Envoyé par souviron34
8OCitation:
Envoyé par nicolas.sitbon
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 ?
Heureusement que ça ne se passe pas comme ça dans la vraie vie....