Je ne sais pas si c'est le cas pour les sockets, mais pour d'autres fonctions Windows il y a deux façons (grosso modo équivalentes) de gérer ce genre de cas : en plus des fonctions bloquantes, il existe des fonctions non bloquantes qui déclenchent un événement ou qui envoient un message lorsqu'il se passe quelque chose d'"intéressant". L'avantage par rapport aux fonctions bloquantes, c'est qu'aussi bien avec les événements que les messages, on peut surveiller plusieurs conditions à la fois sans utiliser de temps CPU. Donc en plus de la condition principale, on peut prévoir une condition pour terminer le thread proprement. Quand l'application doit quitter, le thread principal a juste à envoyer les messages ou déclencher les événements, et à attendre que chaque thread secondaire se termine.

La fonction WSAWaitForMultipleEvents() me laisse supposer que ça marche aussi comme ça pour les sockets, par contre tu risques d'avoir à utiliser les fonctions natives Windows comme WSARecv() au lieu d'une fonction standard comme recv().