C'est très gentil à toi, mais ça ne répond pas à la question posée.
Je sais parfaitement utiliser les pthreads (y compris les signaux,
les masques de signaux et autres joyeusetés). J'ai juste un
problème, SIGINT arrête un peu trop brutalement un programme. Tu me
réponds qu'il faut utiliser des sémaphores, ce qui n'est pas
possible dans mon cas (je ne sais pas quand l'utilisateur aura
l'idée d'envoyer un CTRL+C, donc je ne peux pas protéger cet appel
asynchrone par un sémaphore).
C'est très gentil à toi, mais ça ne répond pas à la question posée.
Je sais parfaitement utiliser les pthreads (y compris les signaux,
les masques de signaux et autres joyeusetés). J'ai juste un
problème, SIGINT arrête un peu trop brutalement un programme. Tu me
réponds qu'il faut utiliser des sémaphores, ce qui n'est pas
possible dans mon cas (je ne sais pas quand l'utilisateur aura
l'idée d'envoyer un CTRL+C, donc je ne peux pas protéger cet appel
asynchrone par un sémaphore).
C'est très gentil à toi, mais ça ne répond pas à la question posée.
Je sais parfaitement utiliser les pthreads (y compris les signaux,
les masques de signaux et autres joyeusetés). J'ai juste un
problème, SIGINT arrête un peu trop brutalement un programme. Tu me
réponds qu'il faut utiliser des sémaphores, ce qui n'est pas
possible dans mon cas (je ne sais pas quand l'utilisateur aura
l'idée d'envoyer un CTRL+C, donc je ne peux pas protéger cet appel
asynchrone par un sémaphore).
JKB wrote:
C'est très gentil à toi, mais ça ne répond pas à la question posée.
Je sais parfaitement utiliser les pthreads (y compris les signaux,
les masques de signaux et autres joyeusetés). J'ai juste un
problème, SIGINT arrête un peu trop brutalement un programme. Tu me
réponds qu'il faut utiliser des sémaphores, ce qui n'est pas
possible dans mon cas (je ne sais pas quand l'utilisateur aura
l'idée d'envoyer un CTRL+C, donc je ne peux pas protéger cet appel
asynchrone par un sémaphore).
Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
JKB <jkb@koenigsberg.invalid> wrote:
C'est très gentil à toi, mais ça ne répond pas à la question posée.
Je sais parfaitement utiliser les pthreads (y compris les signaux,
les masques de signaux et autres joyeusetés). J'ai juste un
problème, SIGINT arrête un peu trop brutalement un programme. Tu me
réponds qu'il faut utiliser des sémaphores, ce qui n'est pas
possible dans mon cas (je ne sais pas quand l'utilisateur aura
l'idée d'envoyer un CTRL+C, donc je ne peux pas protéger cet appel
asynchrone par un sémaphore).
Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
JKB wrote:
C'est très gentil à toi, mais ça ne répond pas à la question posée.
Je sais parfaitement utiliser les pthreads (y compris les signaux,
les masques de signaux et autres joyeusetés). J'ai juste un
problème, SIGINT arrête un peu trop brutalement un programme. Tu me
réponds qu'il faut utiliser des sémaphores, ce qui n'est pas
possible dans mon cas (je ne sais pas quand l'utilisateur aura
l'idée d'envoyer un CTRL+C, donc je ne peux pas protéger cet appel
asynchrone par un sémaphore).
Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
3/ ça ne résiste pas au singe qui appuie plusieurs fois sur CTRL+C
parce qu'il faudrait voir à ne pas oublier de remettre le sémaphore
à un état nul et c'est là qu'il y a un problème au passage
monothread vers multithread ;
4/ je ne sais pas si tu as bien remarqué l'exemple fourni au début
de ce fil, il y avait des points de suspensions, parce que le
programme n'a pas forcément le droit de s'interrompre n'importe
quand (il y a des ressources à libérer dans un certain ordre) et que le
nanosleep() qui pose problème est justement dans une telle boucle.
3/ ça ne résiste pas au singe qui appuie plusieurs fois sur CTRL+C
parce qu'il faudrait voir à ne pas oublier de remettre le sémaphore
à un état nul et c'est là qu'il y a un problème au passage
monothread vers multithread ;
4/ je ne sais pas si tu as bien remarqué l'exemple fourni au début
de ce fil, il y avait des points de suspensions, parce que le
programme n'a pas forcément le droit de s'interrompre n'importe
quand (il y a des ressources à libérer dans un certain ordre) et que le
nanosleep() qui pose problème est justement dans une telle boucle.
3/ ça ne résiste pas au singe qui appuie plusieurs fois sur CTRL+C
parce qu'il faudrait voir à ne pas oublier de remettre le sémaphore
à un état nul et c'est là qu'il y a un problème au passage
monothread vers multithread ;
4/ je ne sais pas si tu as bien remarqué l'exemple fourni au début
de ce fil, il y avait des points de suspensions, parce que le
programme n'a pas forcément le droit de s'interrompre n'importe
quand (il y a des ressources à libérer dans un certain ordre) et que le
nanosleep() qui pose problème est justement dans une telle boucle.
JKB wrote:3/ ça ne résiste pas au singe qui appuie plusieurs fois sur CTRL+C
Si tu cherches pthread + SIGINT dans Google tu peux voir que le premier
message qui arrive porte justement sur ce problème, un seul Ctrl-C
marche, mais une ribambelle en série plante (sous Linux).
Il suit une tonne de commentaires sur la manière de résoudre ce
problème, dont semble t'il la solution qui se dégage est de commencer
dans le programme principal par
- lancer un thread (qui aura pour seule fonction de traîter les signaux)
- puis bloquer tous les signaux intéressants
- puis lancer les threads qui font le boulot. Ils vont hériter à leur
naissance du bloquage des signaux. Bloquer les signaux dans le thread
serait une erreur car soumis à une possibilité de race.
Dans cette situation tu peux être sûr que seul le premier thread va
recevoir les signaux, et tu les traîtes comme tu veux. Si ça doit
terminer l'ensemble, ce thread doit signaler à tous les autres de faire
le nettoyage et mourir, par exemple en modifiant une variable partagée.parce qu'il faudrait voir à ne pas oublier de remettre le sémaphore
à un état nul et c'est là qu'il y a un problème au passage
monothread vers multithread ;
4/ je ne sais pas si tu as bien remarqué l'exemple fourni au début
de ce fil, il y avait des points de suspensions, parce que le
programme n'a pas forcément le droit de s'interrompre n'importe
quand (il y a des ressources à libérer dans un certain ordre) et que le
nanosleep() qui pose problème est justement dans une telle boucle.
Et justement le message que je t'ai indiqué explique comment terminer
proprement l'ensemble des threads. Si tu peux éviter un sémaphore tant
mieux, je ne vois que des emmerdes avec ces trucs là.
JKB <jkb@koenigsberg.invalid> wrote:
3/ ça ne résiste pas au singe qui appuie plusieurs fois sur CTRL+C
Si tu cherches pthread + SIGINT dans Google tu peux voir que le premier
message qui arrive porte justement sur ce problème, un seul Ctrl-C
marche, mais une ribambelle en série plante (sous Linux).
Il suit une tonne de commentaires sur la manière de résoudre ce
problème, dont semble t'il la solution qui se dégage est de commencer
dans le programme principal par
- lancer un thread (qui aura pour seule fonction de traîter les signaux)
- puis bloquer tous les signaux intéressants
- puis lancer les threads qui font le boulot. Ils vont hériter à leur
naissance du bloquage des signaux. Bloquer les signaux dans le thread
serait une erreur car soumis à une possibilité de race.
Dans cette situation tu peux être sûr que seul le premier thread va
recevoir les signaux, et tu les traîtes comme tu veux. Si ça doit
terminer l'ensemble, ce thread doit signaler à tous les autres de faire
le nettoyage et mourir, par exemple en modifiant une variable partagée.
parce qu'il faudrait voir à ne pas oublier de remettre le sémaphore
à un état nul et c'est là qu'il y a un problème au passage
monothread vers multithread ;
4/ je ne sais pas si tu as bien remarqué l'exemple fourni au début
de ce fil, il y avait des points de suspensions, parce que le
programme n'a pas forcément le droit de s'interrompre n'importe
quand (il y a des ressources à libérer dans un certain ordre) et que le
nanosleep() qui pose problème est justement dans une telle boucle.
Et justement le message que je t'ai indiqué explique comment terminer
proprement l'ensemble des threads. Si tu peux éviter un sémaphore tant
mieux, je ne vois que des emmerdes avec ces trucs là.
JKB wrote:3/ ça ne résiste pas au singe qui appuie plusieurs fois sur CTRL+C
Si tu cherches pthread + SIGINT dans Google tu peux voir que le premier
message qui arrive porte justement sur ce problème, un seul Ctrl-C
marche, mais une ribambelle en série plante (sous Linux).
Il suit une tonne de commentaires sur la manière de résoudre ce
problème, dont semble t'il la solution qui se dégage est de commencer
dans le programme principal par
- lancer un thread (qui aura pour seule fonction de traîter les signaux)
- puis bloquer tous les signaux intéressants
- puis lancer les threads qui font le boulot. Ils vont hériter à leur
naissance du bloquage des signaux. Bloquer les signaux dans le thread
serait une erreur car soumis à une possibilité de race.
Dans cette situation tu peux être sûr que seul le premier thread va
recevoir les signaux, et tu les traîtes comme tu veux. Si ça doit
terminer l'ensemble, ce thread doit signaler à tous les autres de faire
le nettoyage et mourir, par exemple en modifiant une variable partagée.parce qu'il faudrait voir à ne pas oublier de remettre le sémaphore
à un état nul et c'est là qu'il y a un problème au passage
monothread vers multithread ;
4/ je ne sais pas si tu as bien remarqué l'exemple fourni au début
de ce fil, il y avait des points de suspensions, parce que le
programme n'a pas forcément le droit de s'interrompre n'importe
quand (il y a des ressources à libérer dans un certain ordre) et que le
nanosleep() qui pose problème est justement dans une telle boucle.
Et justement le message que je t'ai indiqué explique comment terminer
proprement l'ensemble des threads. Si tu peux éviter un sémaphore tant
mieux, je ne vois que des emmerdes avec ces trucs là.
Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
À (at) Tue, 9 Oct 2012 14:36:49 +0000 (UTC),
(Michel Talon) écrivait (wrote):Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'importe
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
À (at) Tue, 9 Oct 2012 14:36:49 +0000 (UTC),
talon@lpthe.jussieu.fr (Michel Talon) écrivait (wrote):
Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'importe
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
À (at) Tue, 9 Oct 2012 14:36:49 +0000 (UTC),
(Michel Talon) écrivait (wrote):Une recherche Google sur pthreads + SIGINT te donne une floppée de
résultats montrant que le problème est complexe. Par exemple:
http://stackoverflow.com/questions/6621785/posix-pthread-programming
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'importe
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'imp orte
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'imp orte
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'imp orte
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
Paul Gaborit writes:
[...]First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'impor te
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
Ce n'est normalement nécessaire que dans les processus qui utilisent des
threads. Dans le cas contraire, il n'y a pas de concurrence, le
gestionnaire fait sa cuisine, et quand le programme reprend son cours il
voit l'effet du gestionnaire (typiquement, positionner un flag).
Le problème, c'est que JKB est tombé sur un cas où il n'a pas deman dé de
thread mais en a quand même. Du coup il a tous les inconvénients, sans
les avantages : la séquence est brisée, son programme reprend son cou rs
avant que le gestionnaire ait fini son travail.
Paul Gaborit <Paul.Gaborit@invalid.invalid> writes:
[...]
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'impor te
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
Ce n'est normalement nécessaire que dans les processus qui utilisent des
threads. Dans le cas contraire, il n'y a pas de concurrence, le
gestionnaire fait sa cuisine, et quand le programme reprend son cours il
voit l'effet du gestionnaire (typiquement, positionner un flag).
Le problème, c'est que JKB est tombé sur un cas où il n'a pas deman dé de
thread mais en a quand même. Du coup il a tous les inconvénients, sans
les avantages : la séquence est brisée, son programme reprend son cou rs
avant que le gestionnaire ait fini son travail.
Paul Gaborit writes:
[...]First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'impor te
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
Ce n'est normalement nécessaire que dans les processus qui utilisent des
threads. Dans le cas contraire, il n'y a pas de concurrence, le
gestionnaire fait sa cuisine, et quand le programme reprend son cours il
voit l'effet du gestionnaire (typiquement, positionner un flag).
Le problème, c'est que JKB est tombé sur un cas où il n'a pas deman dé de
thread mais en a quand même. Du coup il a tous les inconvénients, sans
les avantages : la séquence est brisée, son programme reprend son cou rs
avant que le gestionnaire ait fini son travail.
À (at) Tue, 09 Oct 2012 21:51:15 +0200,
Alain Ketterlin écrivait (wrote):Paul Gaborit writes:
[...]First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'importe
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
Ce n'est normalement nécessaire que dans les processus qui utilisent des
threads. Dans le cas contraire, il n'y a pas de concurrence, le
gestionnaire fait sa cuisine, et quand le programme reprend son cours il
voit l'effet du gestionnaire (typiquement, positionner un flag).
Le problème, c'est que JKB est tombé sur un cas où il n'a pas demandé de
thread mais en a quand même. Du coup il a tous les inconvénients, sans
les avantages : la séquence est brisée, son programme reprend son cours
avant que le gestionnaire ait fini son travail.
Je pense bien avoir compris la situation.
Ce que j'aimerai savoir c'est, lorsqu'on écrit un programme, quel est le
critère pour déterminer s'il va tomber dans l'un ou l'autre des deux cas
(le cas "normal" ou il n'y a pas concurrence et celui où le signal est
traité par un thread).
À (at) Tue, 09 Oct 2012 21:51:15 +0200,
Alain Ketterlin <alain@dpt-info.u-strasbg.fr> écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> writes:
[...]
First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'importe
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
Ce n'est normalement nécessaire que dans les processus qui utilisent des
threads. Dans le cas contraire, il n'y a pas de concurrence, le
gestionnaire fait sa cuisine, et quand le programme reprend son cours il
voit l'effet du gestionnaire (typiquement, positionner un flag).
Le problème, c'est que JKB est tombé sur un cas où il n'a pas demandé de
thread mais en a quand même. Du coup il a tous les inconvénients, sans
les avantages : la séquence est brisée, son programme reprend son cours
avant que le gestionnaire ait fini son travail.
Je pense bien avoir compris la situation.
Ce que j'aimerai savoir c'est, lorsqu'on écrit un programme, quel est le
critère pour déterminer s'il va tomber dans l'un ou l'autre des deux cas
(le cas "normal" ou il n'y a pas concurrence et celui où le signal est
traité par un thread).
À (at) Tue, 09 Oct 2012 21:51:15 +0200,
Alain Ketterlin écrivait (wrote):Paul Gaborit writes:
[...]First of all, signal handlers are a pain. Unless you're very careful,
you have to assume most library functions are not legal to call from a
signal handler. Fortunately, sem_post is specified to be
async-signal-safe, and can meet your requirements perfectly:
At the beginning of your program, initialize a semaphore with
sem_init(&exit_sem, 0, 0);
Install a signal handler for SIGINT (and any other termination signals
you want to handle, like SIGTERM) that performs sem_post(&exit_sem); and
returns.
Replace the for(;;); in the main thread with while
(sem_wait(&exit_sem)!=0).
After sem_wait succeeds, the main thread should inform all other threads
that they should exit, then wait for them all to exit.
Juste pour comprendre: le comportement décrit ici est celui de n'importe
quel processus ou ce comportement ne concerne que les processus
utilisant la bibliothèque pthreads ?
Ce n'est normalement nécessaire que dans les processus qui utilisent des
threads. Dans le cas contraire, il n'y a pas de concurrence, le
gestionnaire fait sa cuisine, et quand le programme reprend son cours il
voit l'effet du gestionnaire (typiquement, positionner un flag).
Le problème, c'est que JKB est tombé sur un cas où il n'a pas demandé de
thread mais en a quand même. Du coup il a tous les inconvénients, sans
les avantages : la séquence est brisée, son programme reprend son cours
avant que le gestionnaire ait fini son travail.
Je pense bien avoir compris la situation.
Ce que j'aimerai savoir c'est, lorsqu'on écrit un programme, quel est le
critère pour déterminer s'il va tomber dans l'un ou l'autre des deux cas
(le cas "normal" ou il n'y a pas concurrence et celui où le signal est
traité par un thread).
[...] Je suis en train de creuser le truc avec les gens de NetBSD,
mais pour l'instant, rien ne se dessine.
[...] Je suis en train de creuser le truc avec les gens de NetBSD,
mais pour l'instant, rien ne se dessine.
[...] Je suis en train de creuser le truc avec les gens de NetBSD,
mais pour l'instant, rien ne se dessine.