Je sais comment envoyer des signaux au processus d'enfant en C à l'aide du Kill (pid_t pid, int SIG) fonction. Qu'en est-il d'envoyer des signaux aux threads? c'est possible?. Si oui, comment attraper des signaux sur le fil "enfant". Par exemple, si le fil principal m'envoie un signal de terminaison, comment puis-je entrer dans l'autre thread l'attraper.
4 Réponses :
Je ne suis pas sûr que cela soit possible car il est dépendant de la plate-forme et de la mise en œuvre et je suggère fortement que vous n'utilisez pas de signaux pour communiquer entre les threads. Parfois, seuls un fil spécifique recevront des signaux et parfois tous les filets reçoivent des signaux.
Meilleurs Mécanismes de communication de fil existent comme des files d'attente, des sémaphores et des serrures.
Les signaux n'ont pas d'affinité de fil. Ils sont manipulés de manière complètement asynchrone. Lorsque vous spécifiez un gestionnaire de signal avec On dirait que vous voulez une autre sorte de communication interthile. Le moyen le plus simple de le faire est avec une variable partagée Si vous avez besoin de contrôle de la concurrence plus forte, examinez les mutiles, les variables de condition et sémaphores. Signal (2) ou sigaction (2) , c'est un gestionnaire de signal global. Lorsqu'un signal est soulevé, le gestionnaire de signal fonctionne sur la pile de tout le fil se déroule à fonctionner à l'époque, et vous ne pouvez pas contrôler cela.
avec des threads POSIX, vous avez les fonctions Le fil signalé doit bloquer sur un Considérant l'analogie avec des signaux livrés aux processus, ceci est un peu différent car Le thread signalé a déjà suspendu son exécution en attente d'un signal, contrairement à un processus qui est simplement interrompu et continue. pthread_cond_wait et pthread_cond_signal . pthread_cond_wait appeler jusqu'à ce qu'un autre thread envoie un signal à l'aide de pthread_cond_signal , avec la même variable d'état.
Ceci est plutôt différent des signaux. Bien que je conviens que c'est généralement une meilleure approche, pthread_kill est la réponse à la question de l'OP, je pense.
@R.
Les signaux sont envoyés à un processus dans son ensemble. Chaque signal envoyé au processus est reçu par un seul fil (au nom de l'ensemble du programme). Il y a des masques de signaux par thread qui influencent si un thread particulier est éligible pour gérer un signal particulier.
Donc, vous avez besoin d'un gestionnaire de signal - éventuellement dans un seul fil. Notez que des limites sont censées faire dans un gestionnaire de signal de fil. Se méfier de marcher loin à l'extérieur des promesses faites par la norme (qui sont minimes).
Cependant, le pthread_kill () fonction peut être utilisé Pour envoyer des signaux à d'autres threads tant que le thread actuel peut identifier (a accès aux valeurs d'ID de thread ( pthread_t ) qui identifient) les threads qui s'exécutent toujours dans le processus. Vous pouvez décider de relâcher le signal aux autres threads à l'aide d'un numéro de signal différent de celui à l'origine capturé (un fil de thème reçoit donc le signal externe, mais de nombreux threads reçoivent le signal interne). Ou vous pouvez utiliser une autre synchronisation de Pthread ou une autre primitive de communication au lieu de signaux.
Je clarifierais "a accès à l'ID de thread". En termes d'exactitude formelle, même si vous avez le pthread_t stocké, il n'est pas valide (comportement non défini) pour en utiliser si le thread peut avoir terminé dans un état détaché ou avec un autre fil appelant déjà < Code> pthread_join dessus.