Je travaille sous Unix (qnx6) compilateur gcc.
J'ai un programme composé de 2 threads.
Si j'envoies un signal du type SIGQUIT vers le programme,
(sous qnx la commande est: slay -s SIGQUIT monprogramme)
le 1er thread de base (père) reçoit bien ce signal et je le contrôle avec
signal(SIGQUIT,mafonction);
Que se passe-t-il à ce moment au niveau du 2d thread ?
Reçoit-il aussi le signal et comment le contrôler?
Merci à tous
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Boyer
DomiPi wrote:
Je travaille sous Unix (qnx6) compilateur gcc. J'ai un programme composé de 2 threads. Si j'envoies un signal du type SIGQUIT vers le programme, (sous qnx la commande est: slay -s SIGQUIT monprogramme) le 1er thread de base (père) reçoit bien ce signal et je le contrôle avec signal(SIGQUIT,mafonction); Que se passe-t-il à ce moment au niveau du 2d thread ? Reçoit-il aussi le signal et comment le contrôler?
Je réponds de mémoire, si quelqu'un veut préciser des choses ou me contredire, qu'il n'hésite pas.
A ma connaissance, un signal est intercepté par *un* thread, et ce thread est indeterminé. Pour spécifier le thread cible, l'API thread posix propose un truc du genre pthread_signal, ou un truc du genre. On peut aussi spécifier un masque par thread, et moi je programmais en dédiant un thread à la gestion des signaux, et en masquant les autres.
Pour plus de détail, il faut attendre que quelqu'un me contredise, ou que tu lises la doc de ton OS.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
DomiPi wrote:
Je travaille sous Unix (qnx6) compilateur gcc.
J'ai un programme composé de 2 threads.
Si j'envoies un signal du type SIGQUIT vers le programme,
(sous qnx la commande est: slay -s SIGQUIT monprogramme)
le 1er thread de base (père) reçoit bien ce signal et je le contrôle avec
signal(SIGQUIT,mafonction);
Que se passe-t-il à ce moment au niveau du 2d thread ?
Reçoit-il aussi le signal et comment le contrôler?
Je réponds de mémoire, si quelqu'un veut préciser des choses
ou me contredire, qu'il n'hésite pas.
A ma connaissance, un signal est intercepté par *un* thread,
et ce thread est indeterminé. Pour spécifier le thread cible,
l'API thread posix propose un truc du genre pthread_signal,
ou un truc du genre. On peut aussi spécifier un masque par
thread, et moi je programmais en dédiant un thread à la
gestion des signaux, et en masquant les autres.
Pour plus de détail, il faut attendre que quelqu'un me
contredise, ou que tu lises la doc de ton OS.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Je travaille sous Unix (qnx6) compilateur gcc. J'ai un programme composé de 2 threads. Si j'envoies un signal du type SIGQUIT vers le programme, (sous qnx la commande est: slay -s SIGQUIT monprogramme) le 1er thread de base (père) reçoit bien ce signal et je le contrôle avec signal(SIGQUIT,mafonction); Que se passe-t-il à ce moment au niveau du 2d thread ? Reçoit-il aussi le signal et comment le contrôler?
Je réponds de mémoire, si quelqu'un veut préciser des choses ou me contredire, qu'il n'hésite pas.
A ma connaissance, un signal est intercepté par *un* thread, et ce thread est indeterminé. Pour spécifier le thread cible, l'API thread posix propose un truc du genre pthread_signal, ou un truc du genre. On peut aussi spécifier un masque par thread, et moi je programmais en dédiant un thread à la gestion des signaux, et en masquant les autres.
Pour plus de détail, il faut attendre que quelqu'un me contredise, ou que tu lises la doc de ton OS.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
DomiPi
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT. Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail. Mais comment faire, là je cale ... Merci Dominique
"Marc Boyer" a écrit dans le message de news:boaev5$3pc$
DomiPi wrote:
Je travaille sous Unix (qnx6) compilateur gcc. J'ai un programme composé de 2 threads. Si j'envoies un signal du type SIGQUIT vers le programme, (sous qnx la commande est: slay -s SIGQUIT monprogramme) le 1er thread de base (père) reçoit bien ce signal et je le contrôle avec
signal(SIGQUIT,mafonction); Que se passe-t-il à ce moment au niveau du 2d thread ? Reçoit-il aussi le signal et comment le contrôler?
Je réponds de mémoire, si quelqu'un veut préciser des choses ou me contredire, qu'il n'hésite pas.
A ma connaissance, un signal est intercepté par *un* thread, et ce thread est indeterminé. Pour spécifier le thread cible, l'API thread posix propose un truc du genre pthread_signal, ou un truc du genre. On peut aussi spécifier un masque par thread, et moi je programmais en dédiant un thread à la gestion des signaux, et en masquant les autres.
Pour plus de détail, il faut attendre que quelqu'un me contredise, ou que tu lises la doc de ton OS.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
C'est une bonne idée de dédier le traitement des signaux à un seul thread:
dans mon cas par exemple le thread de base(père). C'est ce que je fait
actuellement pour terminer "proprement" son travail qnand il reçoit un
SIGQUIT.
Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en
ai qu'un) pour qu'il termine aussi "proprement" son travail.
Mais comment faire, là je cale ...
Merci
Dominique
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:boaev5$3pc$2@news.cict.fr...
DomiPi wrote:
Je travaille sous Unix (qnx6) compilateur gcc.
J'ai un programme composé de 2 threads.
Si j'envoies un signal du type SIGQUIT vers le programme,
(sous qnx la commande est: slay -s SIGQUIT monprogramme)
le 1er thread de base (père) reçoit bien ce signal et je le contrôle
avec
signal(SIGQUIT,mafonction);
Que se passe-t-il à ce moment au niveau du 2d thread ?
Reçoit-il aussi le signal et comment le contrôler?
Je réponds de mémoire, si quelqu'un veut préciser des choses
ou me contredire, qu'il n'hésite pas.
A ma connaissance, un signal est intercepté par *un* thread,
et ce thread est indeterminé. Pour spécifier le thread cible,
l'API thread posix propose un truc du genre pthread_signal,
ou un truc du genre. On peut aussi spécifier un masque par
thread, et moi je programmais en dédiant un thread à la
gestion des signaux, et en masquant les autres.
Pour plus de détail, il faut attendre que quelqu'un me
contredise, ou que tu lises la doc de ton OS.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT. Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail. Mais comment faire, là je cale ... Merci Dominique
"Marc Boyer" a écrit dans le message de news:boaev5$3pc$
DomiPi wrote:
Je travaille sous Unix (qnx6) compilateur gcc. J'ai un programme composé de 2 threads. Si j'envoies un signal du type SIGQUIT vers le programme, (sous qnx la commande est: slay -s SIGQUIT monprogramme) le 1er thread de base (père) reçoit bien ce signal et je le contrôle avec
signal(SIGQUIT,mafonction); Que se passe-t-il à ce moment au niveau du 2d thread ? Reçoit-il aussi le signal et comment le contrôler?
Je réponds de mémoire, si quelqu'un veut préciser des choses ou me contredire, qu'il n'hésite pas.
A ma connaissance, un signal est intercepté par *un* thread, et ce thread est indeterminé. Pour spécifier le thread cible, l'API thread posix propose un truc du genre pthread_signal, ou un truc du genre. On peut aussi spécifier un masque par thread, et moi je programmais en dédiant un thread à la gestion des signaux, et en masquant les autres.
Pour plus de détail, il faut attendre que quelqu'un me contredise, ou que tu lises la doc de ton OS.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer
DomiPi wrote:
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT. Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail. Mais comment faire, là je cale ...
man pthread_kill
Ton thread père envois des signaux de terminaison aux fils.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
DomiPi wrote:
C'est une bonne idée de dédier le traitement des signaux à un seul thread:
dans mon cas par exemple le thread de base(père). C'est ce que je fait
actuellement pour terminer "proprement" son travail qnand il reçoit un
SIGQUIT.
Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en
ai qu'un) pour qu'il termine aussi "proprement" son travail.
Mais comment faire, là je cale ...
man pthread_kill
Ton thread père envois des signaux de terminaison aux fils.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT. Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail. Mais comment faire, là je cale ...
man pthread_kill
Ton thread père envois des signaux de terminaison aux fils.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Laurent Wacrenier
DomiPi écrit:
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT.
Changer le masque des signaux reçus avec pthread_sigmask. Pour bien faire, si tu veux que le père intercepte les signaux, lance un pthread_sigmask sur le père, fait ton pthread_create puis remet le masque de signaux sur le père à sa valeur originelle.
Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail.
Lui envoyer un pthread_cancel()
DomiPi <akuj0006@wanadoo.be> écrit:
C'est une bonne idée de dédier le traitement des signaux à un seul thread:
dans mon cas par exemple le thread de base(père). C'est ce que je fait
actuellement pour terminer "proprement" son travail qnand il reçoit un
SIGQUIT.
Changer le masque des signaux reçus avec pthread_sigmask. Pour bien
faire, si tu veux que le père intercepte les signaux, lance un
pthread_sigmask sur le père, fait ton pthread_create puis remet le
masque de signaux sur le père à sa valeur originelle.
Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en
ai qu'un) pour qu'il termine aussi "proprement" son travail.
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT.
Changer le masque des signaux reçus avec pthread_sigmask. Pour bien faire, si tu veux que le père intercepte les signaux, lance un pthread_sigmask sur le père, fait ton pthread_create puis remet le masque de signaux sur le père à sa valeur originelle.
Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail.
Lui envoyer un pthread_cancel()
Erwann ABALEA
On Wed, 5 Nov 2003, DomiPi wrote:
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT. Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail. Mais comment faire, là je cale ...
Ah ben c'est une autre question... C'est un problème de communication entre threads.
Personnellement, je verrais ça comme ça: - le père (ou autre, celui qui reçoit les signaux) reçoit donc un signal, lui disant de se casser - il lève un drapeau, dédié à cet usage - les fils (ou les autres threads, puisqu'il n'y a pas de notion père/fils) surveillent le drapeau de temps en temps, et agissent en conséquence
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- 70% de frjv sont des newbies ? Et une fois qu'ils ne le sont plus que font-ils ? Ils quittent frjv parce que c'est trop à chier ? Parce que s'ils y restent et gardent leur comportement, ça devient des neuneux. -+- XB in: Guide du Neuneu d'Usenet - Tu seras un neuneu mon fils -+-
On Wed, 5 Nov 2003, DomiPi wrote:
C'est une bonne idée de dédier le traitement des signaux à un seul thread:
dans mon cas par exemple le thread de base(père). C'est ce que je fait
actuellement pour terminer "proprement" son travail qnand il reçoit un
SIGQUIT.
Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en
ai qu'un) pour qu'il termine aussi "proprement" son travail.
Mais comment faire, là je cale ...
Ah ben c'est une autre question... C'est un problème de communication
entre threads.
Personnellement, je verrais ça comme ça:
- le père (ou autre, celui qui reçoit les signaux) reçoit donc un
signal, lui disant de se casser
- il lève un drapeau, dédié à cet usage
- les fils (ou les autres threads, puisqu'il n'y a pas de notion
père/fils) surveillent le drapeau de temps en temps, et agissent en
conséquence
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
70% de frjv sont des newbies ? Et une fois qu'ils ne le sont plus que
font-ils ? Ils quittent frjv parce que c'est trop à chier ? Parce que
s'ils y restent et gardent leur comportement, ça devient des neuneux.
-+- XB in: Guide du Neuneu d'Usenet - Tu seras un neuneu mon fils -+-
C'est une bonne idée de dédier le traitement des signaux à un seul thread: dans mon cas par exemple le thread de base(père). C'est ce que je fait actuellement pour terminer "proprement" son travail qnand il reçoit un SIGQUIT. Dans ce cas je voudrais que le thread père puisse prévenir le fils (car j'en ai qu'un) pour qu'il termine aussi "proprement" son travail. Mais comment faire, là je cale ...
Ah ben c'est une autre question... C'est un problème de communication entre threads.
Personnellement, je verrais ça comme ça: - le père (ou autre, celui qui reçoit les signaux) reçoit donc un signal, lui disant de se casser - il lève un drapeau, dédié à cet usage - les fils (ou les autres threads, puisqu'il n'y a pas de notion père/fils) surveillent le drapeau de temps en temps, et agissent en conséquence
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- 70% de frjv sont des newbies ? Et une fois qu'ils ne le sont plus que font-ils ? Ils quittent frjv parce que c'est trop à chier ? Parce que s'ils y restent et gardent leur comportement, ça devient des neuneux. -+- XB in: Guide du Neuneu d'Usenet - Tu seras un neuneu mon fils -+-
