reveiller un thread en attente sur clock_nanosleep

Bonjour a tous,

J'ai un thread qui est endormi jusqu’à un temps de timeout sur fonction clock_nanosleep().
Dans le cas ou je souhaite l'interrompre avant la fin. je compte lui envoyer un signal via pthread_kill() avec un signal réel time (SIGRTMIN + n) ou SIGUSR1/2.

Voici mes questions:
1 - Est-ce que l'utilisation du signal est le meilleur moyen pour réveiller le thread?
2 - Si oui, l'utilisation du signal reel time (SIGRTMIN + n), ou SIGUSR est elle bonne?
3 - Dans le cas ou je lance un SIGINT sur mon programme (ctrl-c) pour le terminer. Commment savoir que mon thread timer est interrompu soit par SIGINT soit par SIGUSR/(SIGRTMIN + n)? dois je avoir une variable via un booleen/enum qui met dit le dernier type de signal reçu?

Je vous remercie.
Cordialement,

Bonjour,

1- Pour arrêter un clock_nanosleep() il n'y a que les signaux. Sinon il faut mettre en place un mécanisme de communication plus évolué (pipe, etc...)
2- tout signal non destructif est utilisable pour cela, donc les SIGRTMIN et les SIGUSR sont tout à fait adaptés
3- Un signal, ça casse une fonction d'attente parmi les threads qui tournent. On peut utiliser une callback qui détecte le signal attendu et le note. Puis si le clock_nanosleep() retourne un temps restant, on peut vérifier qu'il ne s'agit pas de celui attendu et donc de se remettre en attente du temps restant.
Attention, si l'application a plusieurs threads cela est nettement plus compliqué ou plus simple (en utilisant mal ou bien les masquages des signaux.)

Merci pour tes reponses!!

la methode posix pthread_kill prend le thread id argument, je pensais envoyé le signal via cette méthode sans passer par l’intégration du signal dans le vecteur d'interruption (via la methode sigaction()).
A ce moment la pas de problème de masquages ? ou je me trompe?

En effet pthread_kill est directif. Il faut cependant tenir compte des autres signaux qui se déclencheront sur un thread quelconque qui ne les masque pas.

Ca marche merci pour cette précision
Topic resolu !!!

Bonjour,

Je me permets de ré-ouvrir ce topic car des questions subsidiaires sont apparus:


1- Je souhaite envoyer un signal avec la fonction pthread_kill(threadId, Signal-RT) de l'API posix a un thread pour qu'il sorte de la fonction clock_nanosleep(). Que se passe-t- dans le cas ou le thread reçoit le signal alors qu'il n'est pas en attente dans la fonction clock_nanosleep??

2- Est il préférable modifier l’ignorance ou non de ce signal a chaque fois qu'il rentre dans la méthode clock_nanosleep() :
- traitement ....
- Avant clock_nanosleep j'autorise l'interruption via sigmask
- clock_nanosleep
- Apres clock_nanosleep j'ignore l'interruption via sigmask
- traitement ....
- ... loop

3- J'etais part dans l'idéee de lancer seulement un pthread_kill sans vecteur d'interruption, mais :
Est ce que c'est plus "propre" de lancer un pthread_kill pour ce thread "à la volé", ou de créer une routine d'interruption pour ce signal et de gérer les masques des threads en fonction ? Sachant que seulement un seul thread sera affecté par ce signal

Merci par avance

Citation:

---

Envoyé par boubouboy

Que se passe-t- dans le cas ou le thread reçoit le signal alors qu'il n'est pas en attente dans la fonction clock_nanosleep??

---

Tant qu'aucune fonction d'aucun thread n'est en attente, il ne se passe rien pour la plupart des signaux (dont USR et RT), le signal reste à l'affut de son déclenchement. La prochaine fonction d'attente quelle qu'elle soit sera débloquée, il en existe de partout, par exemple un printf().

Citation:

---

Envoyé par boubouboy

Est il préférable modifier l’ignorance ou non de ce signal a chaque fois qu'il rentre dans la méthode clock_nanosleep() :
- traitement ....
- Avant clock_nanosleep j'autorise l'interruption via sigmask
- clock_nanosleep
- Apres clock_nanosleep j'ignore l'interruption via sigmask
- traitement ....
- ... loop

---

C'est en effet une bonne méthode, on bloque ce signal partout sauf là où on accepte de le recevoir.

Citation:

---

Envoyé par boubouboy

J'etais part dans l'idéee de lancer seulement un pthread_kill sans vecteur d'interruption, mais :
Est ce que c'est plus "propre" de lancer un pthread_kill pour ce thread "à la volé", ou de créer une routine d'interruption pour ce signal et de gérer les masques des threads en fonction ? Sachant que seulement un seul thread sera affecté par ce signa

---

Ça n'est pas la routine qui masque, elle est associée à un mécanisme de masquage. Comme ici le signal est directif, il n'y a rien de spécial à prévoir sur les autres threads.

Super merci pour ces éclaircissements.

Je pense que vous avez répondu à toutes mes questions .