Recherche:

Oui, c'est juste. OK, merci pour l'explication. J'ai saisi maintenant.

D'accord, et donc au prochain select(), si la socket #1 est identifiée dans readfs, alors cela signifie que recv() ne bloquera pas, c'est bien cela?

Désolé mais je ne comprends toujours pas votre explication. Vous utilisez select() sur 2 sockets: la #1 qui sert à la communication avec les clients et la #2 qui permet d'envoyer des messages de...

Je ne saisis pas. Il faut bien que quelqu'un le fasse ce recv()?!?! En outre, select() permet juste de savoir si accept() retournera, non? Cela ne garantit pas que recv() retournera aussi.

Et alors? Ce problème existe de toute façon, même en dehors de la question d'arrêter proprement le thread#1.

Pas besoin d'utiliser select(). Le thread #2 se connecte sur le port écouté par le thread #1 (thread que l'on souhaite arrêter). Le thread #1 est donc débloqué (accept() retourne). Le thread #1 fait...

Ca tombe sous le sens; je n'ai pas décrit toutes les étapes mais juste la trame générale à suivre.

C'est justement à cela que sert le message de fin. Le thread (#1) en question est à l'écoute (listen()) et accepte les connexions. Lorsque l'on souhaite arrêter ce thread (qui bloque sur un accept()...

Une solution consisterait à définir un message de fin. Lorsque le dit thread reçoit ce message, il arrête tout et se termine.