Discussion :

[jeje99]

Bonjours à tous,

Comme l'indique mon sujet vais vous posez une question sur les sockets non bloquante.

Ce que je voudrais savoir c'est comment faire pour qu'un thread autre que celui ou tourne le select, puisse débloquer cette fonction. Pour cela j'imagine qu'il faut que j'ouvre un socket en interne à mon application.

Quel est le moyen le plus propre sous Windows pour faire ça tout en respectant une certaine portabilité ? Je suis prenneur de tout code source exemple...

[fearyourself]

Bonjours à tous,
Ce que je voudrais savoir c'est comment faire pour qu'un thread autre que celui ou tourne le select, puisse débloquer cette fonction.

Pourquoi ne pas simplement mettre un timer pour que le select arrête après un certain temps? C'est à ça que sert le dernier argument...

Jc

[jeje99]

j'aimerais pas trop faire ça.

En fait mon application gette des évènements et les envoi à travers les socket qui vont bien.

Le problème c'est que ces évènements ne sont pas liés au socket. Et sont gérés par un autre thread. Quand ces évènements interviennent j'aimerais débloquer le select plutôt qu'il fasse échoir un time out et vérifie de lui même ça risquerais d'occuper le processeur pour rien (mes évènements sont aléatoire).

[Emmanuel Delahaye]

En fait mon application gette

Argh ! guette !

des évènements et les envoi à travers les socket qui vont bien.

Le problème c'est que ces évènements ne sont pas liés au socket. Et sont gérés par un autre thread. Quand ces évènements interviennent j'aimerais débloquer le select plutôt qu'il fasse échoir un time out et vérifie de lui même ça risquerais d'occuper le processeur pour rien (mes évènements sont aléatoire).

Dans ce cas, ce n'est pas select() qu'il faut utiliser pour bloquer, mais une synchronisation. Voir les conditions... (pthread_cond_t)

http://emmanuel-delahaye.developpez.com/pthreads.htm

[jeje99]

En fait ce n'est pas que dans un sens. Il peut arriver que des informations arrive aussi des socket.

Les mutex ne seront donc pas suffisant, il me faut donc un moyen de surveiller les flux dans les deux sens.

Je pense que select peut le faire mais je ne sais pas comment surveiller autre chose qu'un socket de type AF_INET sous windows ?

[Emmanuel Delahaye]

En fait ce n'est pas que dans un sens. Il peut arriver que des informations arrive aussi des socket.

Les mutex ne seront donc pas suffisant, il me faut donc un moyen de surveiller les flux dans les deux sens.

Alors il faut un thread pour les sockets avec select() et un autre avec une condition.

C'est un problème d'architecture de logiciel (conception), pas de langage C...

[jeje99]

Bon sang mais c'est bien sur ... (désolé j'ai pas pu m'en empècher)

Bon il me reste plus qu'a trouver un moyen pour gérer un mutex par socket, et c'est bon !


Merci de m'avoir débloqué !

[jeje99]

En fait, je me suis un peut emporté, il me reste un petit hic...

Je ne programme pas un serveur habituel, mais plutôt un super client qui lance des connexions. Donc dans mon, je ne peux pas utiliser de socket en écoute pour débloquer ma fonction select lors d'une nouvelle connexion.

La création de mes sockets clients se fait par la fonction socket et connect() d'après un ordre du thread gérant les évènement. C'est pourquoi j'aurais besoin que la fonction select se débloque grâce à un évènement de manière à pouvoir créer ce socket.

[loufoque]

Tu peux parfaitement faire un select() sur la socket sur laquelle tu attends des connexions.
Si select() te dit qu'il y a des données en écriture sur cette socket, cela signifie qu'il y a une connexion en attente que tu peux récupérer avec accept().

[jeje99]

C'est justement ça mon problème, c'est que je n'écoute pas sur un socket.
Je veux gérer un pool de client connecté à différents serveur.

Donc pour faire communiquer mes threads entre eux, il faudrait que j'ouvre un socket en interne, ce que je ne sais pas faire.

[Emmanuel Delahaye]

C'est justement ça mon problème, c'est que je n'écoute pas sur un socket.
Je veux gérer un pool de client connecté à différents serveur.

Donc pour faire communiquer mes threads entre eux, il faudrait que j'ouvre un socket en interne, ce que je ne sais pas faire.

PF_UNIX

[Emmanuel Delahaye]

Je pense que select peut le faire mais je ne sais pas comment surveiller autre chose qu'un socket de type AF_INET sous windows ?

Tu veux bien sûr dire PF_INET...

[jeje99]

N'oublions que je suis avant tout sous Windows, et j'ai cru comprendre que les socket PF_UNIX ne fonctionne pas sous cet OS(sous unix ça aurait été réglé plus vite :-).

Enfin j'ai trouvé quelquchose qui m'intéresse bien dans le topic :

http://www.developpez.net/forums/viewtopic.php?t=425288

Ah, oui, alors là, ça ne doit pas marcher: sous unixoïde, select() marche sur des descripteurs, et les sockets en sont, mais sous Windows, select() marche sur les sockets, qui sont des HANDLEs...

Par contre, il serait intéressant de tester select() sur un handle autre qu'un socket (à mon avis, select() utilise WaitForMultipleObjects()). On peut récupérer les handles des IO standards avec GetStdHandle()...

Le problème c'est qu'avec le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
	HANDLE handleInput = GetStdHandle(STD_INPUT_HANDLE);
 
       // Initialize the Read and Write socket set.
       FD_ZERO(&Reader);
       FD_ZERO(&Writer);
	FD_SET(sock, &Reader); 
 
	FD_SET(handleInput, &Reader);
      // Set Read and Write notification for each socket based on the
       // current state the buffer. 
 
   nbSocket = select(0, &Reader, &Writer, NULL, NULL);

La compilation ne passe pas, est -ce que select focntionne à partir d'Handle ?

[loufoque]

N'oublions que je suis avant tout sous Windows, et j'ai cru comprendre que les socket PF_UNIX ne fonctionne pas sous cet OS

Ben c'est pareil, t'utilises une socket inet à la place d'une socket unix, c'est tout.

[Médinoc]

Pour le socket en interne, coté "serveur", tu effectues un bind() avec un numéro de port nul, le socket se liera à un port disponible.
Ensuite, un getsockname() permet de récupérer le N° de port en question, et de te connecter dessus (adresse 127.0.0.1) avec un autre socket...


PS: quand je clique sur ton lien, je tombe sur un topic de moins d'une page, et je n'y retrouve pas ta citation (bien que je pense qu'elle est de moi).
Toujours est-il quque si je me souviens bien, le coup du WaitForMultipleObjects() sur des sockets a été essayé sans succès par la suite.

[jeje99]

Merci pour ces réponses, j'essaye ça tout de suite :-)

Pour ce qui est de la citation effectivement je me suis trouvé d'url, la bonne est :
http://www.developpez.net/forums/viewtopic.php?t=420007