Discussion :

[Gruik]

Salux,

J'ai une application qui fait un traitement assez long et, en parallele je devrais avoir une partie qui receptionne des "requetes" permettant notamment de savoir où ça en est.
Il s'avere que je ne puisse peut etre pas utiliser les Fifos alors j'ai pensé aux sockets (domaine Unix).
Je prefererais eviter aussi les sockets non bloquantes, du coup on se retrouve forcement avec un schema multi-thread, ou multi-process

J'étais en train de jeter un oeil sur les threads et je ne vois pas vraiment de mecanisme permettant de stopper proprement l'eventuel thread (qui serait bloqué par accept())
Dans ces cas là, la seule solution serait fork+signal ?

Mercix

[stephl]

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

[lun4t1k]

Et apres tu te retrouves a faire un serveur concurrent que tu quittes en gérant le signal sigint.
mais sinon le fameux "quit" quand tu veux quitter!

[souviron34]

Salux,

J'ai une application qui fait un traitement assez long et, en parallele je devrais avoir une partie qui receptionne des "requetes" permettant notamment de savoir où ça en est.
Il s'avere que je ne puisse peut etre pas utiliser les Fifos alors j'ai pensé aux sockets (domaine Unix).
Je prefererais eviter aussi les sockets non bloquantes, du coup on se retrouve forcement avec un schema multi-thread, ou multi-process

J'étais en train de jeter un oeil sur les threads et je ne vois pas vraiment de mecanisme permettant de stopper proprement l'eventuel thread (qui serait bloqué par accept())
Dans ces cas là, la seule solution serait fork+signal ?

Mercix

Attends.. Quel est le problème exact :

tu voudrais que pendant que ton appli (traitement long) tourne, une partie de cette appli reçoive des requêtes ? ou envoie des statuts ? et les recevoir avec une autre appli ?

[Médinoc]

Si tu veux pouvoir terminer proprement un thread qui ne fait que de l'attente de connexion (type accept()) en boucle, je ne vois pas trente-six solutions propres :
Pour moi, tu dois ajouter un second socket pour ce thread, et écouter avec select().
Une tentative de connexion (ou un envoi de données si le socket de contrôle est déjà connecté) sur ce socket et hop! Tu peux quitter ton thread proprement.

De plus, ce second socket peut être juste un socket local, sans port fixe, connu seulement de ton application : Elle peut se connecter dessus en interne, par exemple en cas de réception d'un ordre d'arrêt sur un autre socket.

[Gruik]

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

Oui mais le "thread" serait bloqué par une fonction bloquante

Attends.. Quel est le problème exact :

tu voudrais que pendant que ton appli (traitement long) tourne, une partie de cette appli reçoive des requêtes ?

c'est bien ça

ou envoie des statuts ? et les recevoir avec une autre appli ?

bein elle recevrait des requetes en renverrait une reponse

Si tu veux pouvoir terminer proprement un thread qui ne fait que de l'attente de connexion (type accept()) en boucle, je ne vois pas trente-six solutions propres :
Pour moi, tu dois ajouter un second socket pour ce thread, et écouter avec select().
Une tentative de connexion (ou un envoi de données si le socket de contrôle est déjà connecté) sur ce socket et hop! Tu peux quitter ton thread proprement.

De plus, ce second socket peut être juste un socket local, sans port fixe, connu seulement de ton application : Elle peut se connecter dessus en interne, par exemple en cas de réception d'un ordre d'arrêt sur un autre socket.

D'accord merci
C'est vrai j'avais deja entendu parlé de select, je vais me renseigner dessus

[souviron34]

OK alors pas besoin de multithread, mais (si elle doit ET recevoir ET émettre) effectivement 2 sockets. Socket de réception en asynchrone.

Et en plus (j'ai fait ça dans des serveurs de données), si tu veux juste dire que le traitement est pas fini, un timer qui déclenche l'écriture de "Working..", ou bien directement un appel à une fonction qui va écrire "Working on xxxx".

En fait, c'est une structure de base client serveur, avec reception des 2 côtés en asynchrone.

[souviron34]

Et sinon, j'ai une autre idée (bête...) mais :

si c'est juste pour savoir un truc comme ça, pourquoi simplement ne pas mettre un timer dans l'aplli "surveillante", et toutes les X secondes aller vérifier un fichier où simplement tu écrirais "Je travaille sur ...." ou "j'ai fini".. ?

[stephl]

Oui mais le "thread" serait bloqué par une fonction bloquante

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() s'il n'y a plus de message), le thread #2 qui aura été lancé au préalable, envoie sur le port écouté par le thread #1 le message de fin. Ainsi, le thread #1 se débloque (accept() retourne), reconnaît le message de fin, ferme sa socket et se termine.

[Gruik]

OK alors pas besoin de multithread, mais (si elle doit ET recevoir ET émettre) effectivement 2 sockets. Socket de réception en asynchrone.

Et en plus (j'ai fait ça dans des serveurs de données), si tu veux juste dire que le traitement est pas fini, un timer qui déclenche l'écriture de "Working..", ou bien directement un appel à une fonction qui va écrire "Working on xxxx".

En fait, c'est une structure de base client serveur, avec reception des 2 côtés en asynchrone.

Bein les sockets sont deja bidirectionnelles

Et sinon, j'ai une autre idée (bête...) mais :

si c'est juste pour savoir un truc comme ça, pourquoi simplement ne pas mettre un timer dans l'aplli "surveillante", et toutes les X secondes aller vérifier un fichier où simplement tu écrirais "Je travaille sur ...." ou "j'ai fini".. ?

J'y ai pensé mais ça me semblait pas terrible

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() s'il n'y a plus de message), le thread #2 qui aura été lancé au préalable, envoie sur le port écouté par le thread #1 le message de fin. Ainsi, le thread #1 se débloque (accept() retourne), reconnaît le message de fin, ferme sa socket et se termine.

Ahhh mais c'est bien sur ^^
Si le thread est bloqué par une attente de connexion, suffit que le thread principal s'y connecte lui meme et envoie un message particulier de terminaison...

Groovy

[Médinoc]

Mais pour reconnaitre le message de fin, il faut que le thread qui fait le accept() fasse un recv() en plus sur le socket qu'il vient d'accepter...

[stephl]

Mais pour reconnaitre le message de fin, il faut que le thread qui fait le accept() fasse un recv() en plus sur le socket qu'il vient d'accepter...

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

[Gruik]

Oui, of course qu'il fera un recv juste apres

[Médinoc]

Mais si le client n'envoit rien, le thread du accept() restera bloqué sur le recv() et ne pourra plus rien accepter d'autre.

Sauf bien sûr en utilisant select()...

[Médinoc]

Avec select(), on peut choisir de mettre toute la communication réseau dans le même thread, et par exemple lancer les opérations longues dans des threads à part (ou UN thread (ou encore un pool de threads) avec une file d'attente)...

[Gruik]

Effectivement :/
Enfin ça complique qd meme pas mal, avoir 2 connexions
Mais ya pas le choix

[Gruik]

Au fait pour le file descriptor de communication entre le thread principal et le thread gerant les requetes, ne serait il pas plus simple d'utiliser une pipe?

[souviron34]

Bein les sockets sont deja bidirectionnelles

OUI mais tu peux pas être à la fois asynchrone et synchrone. Et pour écrire faut être synchrone.. Et en plus si tu utilises le même, tu sera réveillé chaque fois que tu écris, même en auto ..

Donc moi quand je fais ça j'en prends 2 : 1 en écoute et un en écriture pour le client et le serveur.

J'y ai pensé mais ça me semblait pas terrible

Tout dépend de l'appli. Mais si le but est strictement juste de dire "j'en suis là", pourquoi faire compliqué alors qu'on peut faire simple ??

[Gruik]

OUI mais tu peux pas être à la fois asynchrone et synchrone. Et pour écrire faut être synchrone.. Et en plus si tu utilises le même, tu sera réveillé chaque fois que tu écris, même en auto ..

Donc moi quand je fais ça j'en prends 2 : 1 en écoute et un en écriture pour le client et le serveur.

oki

Tout dépend de l'appli. Mais si le but est strictement juste de dire "j'en suis là", pourquoi faire compliqué alors qu'on peut faire simple ??

Non ce n'est pas que ça

[stephl]

Mais si le client n'envoit rien, le thread du accept() restera bloqué sur le recv() et ne pourra plus rien accepter d'autre.

Sauf bien sûr en utilisant select()...

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 appel à recv() pour recevoir le message de fin envoyé par le thread #2. Ainsi, le thread #1 peut se terminer. Cette solution fonctionne très bien, je l'ai déjà implémentée avec sucès sur un petit projet clients-serveur.