salut,
sous windows, j'ai pas de probleme, mais sous linux, quel est le moyen pour qu'un thread qui bloque sur un select bloquant se débloque? shutdown(sock, 2) et close(sock) semblent sans effet (ou bien c'est une erreur de ma part qui vient d'ailleurs?!)...
 
en fait j'en suis la:
 
// bind et listen sur le socket viennent d'etre fait.
fd_set set;
FD_ZERO(&set);
FD_SET(sock,&set);
if (select((int) sock + 1,&set,0,0,0) == 1) // ca bloque ici jusqu'a ce qu'un client arrive.
{
// etc.
}
 
depuis un autre thread, j'essaie de fermer sock, mais ca semble pas débloquer le select...
qqun sait comment faire ?
merci

en établissant une connection sur ta socket d'écoute à partir de ton autre thread?

le premier thread fait bind, listen, et select avec le socket sock. avant de faire le bind, il crée un autre thread a qui il passe sock en parametre.
 
depuis l'autre thread, je tente un shutdown(sock,2) et un close(sock). sous windows, le select du premier thread se débloque (et renvoie un SOCKET_ERROR), alors que sous linux, ca semble rester bloqué...

la feinte la marcherait effectivement, mais bon c'est pas propre du tout... ya pas un moyen 'normal' ??

 
C'est bizarre que ça marche mal: je faisais la même chose sous Solaris.
 
En environnement monotâche, on utilise généralement un sigaction et un kill (quoique poll et select avec time-out ont un peu plus ma faveur).
 
Pourquoi ne pas utiliser pthread_sigaction et pthread_kill ici ?

de quoi tu parles qui marche mal, le fait de faire un connect depuis l'autre thread? je dis pas que ca marche mal, mais a mon avis il doit exister une autre maniere de faire...
sinon pour ma part, il m'est impossible d'utiliser le kill de thread (car arret brutal, ce qui n'est pas possible ds mon cas).

 
Nan, ce qui me surprend, c'est que Linux n'ait pas le même comportement que Solaris et Windows lorsque tu fais ton close.
 
Pour ce qui est du pthread_kill, ça devrait théoriquement t'envoyer dans la fonction que tu donnes au sigaction, ou bien je me trompe ?

 
Ce qui est dégueulasse, c'est d'utiliser la socket de manière concurrente dans les deux threads.

La je suis d'accord. Par contre, que penses tu des MFC qui t'interdisent d'utiliser dans un thread une CSocket définie (juste définie) dans le thread principal ?
 
edit: voir ici http://support.microsoft.com/defau [...] US;Q140527

 
Qu'au moins, ça évite de faire ce genre de conneries

est ce non recommandé d'utiliser un meme socket ds deux threads différents? (non recommandé pourquoi? le systeme d'exploitation gere les acces concurrents a un meme socket)jvois pas comment se dépetrer des fonctions bloquantes sans avoir plus q'un thread sur un meme socket... (pouvoir envoyer des donnees alors que le socket attend une reception...)
enfin bref

 
C'est totalement déconseillé sauf si on sait très bien ce que l'on fait. Or ce n'est manifestement pas le cas.
 

 
Vous avez vu ça où? Et même si c'était le cas, c'est le meilleur moyen de pondre un code non-portable et qui, oh, marche sous windows et, oh, ne marche pas sous linux
 

 
Apprenez à lire le man et à utiliser le paramètre timeout du select. Ici, cela n'a rien à voir avec les sockets bloquantes ou non. Vous faites un appel qui bloque indéfiniment et vous trouvez que vous avez un problème parce que votre appel bloque indéfiniment...

j'ai simplifié mon probleme pour pouvoir l'expliquer simplement...
j'ai presque entierement terminé une classe socket portable et qui gere les sockets de maniere asynchrone (l'équivalent des WSAAsync* de win32, mais en portable).
le probleme est qu'au moment de la destruction, je termine la connexion eventuelle, et dans le cas ou le socket avait été utilisé pour un listen, il me faut bien débloquer le select.
 
bon maintenant voila, en quoi la remarque 'C'est totalement déconseillé sauf si on sait très bien ce que l'on fait. Or ce n'est manifestement pas le cas.' est elle constructive? si je poste ici, c'est bien pour connaitre la maniere propre de proceder... je demande de l'aide pour un cas précis qui rentre ds ce que je veux faire, alors pourquoi me dire 'change ce que tu veux faire tu n'as rien compris' ?
 
donc voila

Bon, je ne vais pas me répéter 36 fois. Si vous n'arrivez pas à entendre qu'on n'utilise pas une ressource en même temps dans deux threads et qu'un select sans timeout bloque à l'infini, je n'y peux rien.

amen

 
Amen, cela se traduit par "c'est vrai" en français
Vous me direz, c'est cohérent avec votre utilisation des sockets.

tu te faisais taper par les autres pendant ton enfance? compare le ton de tes réponses avec celles des autres, et remarque a quel point t'es désagréable...
 
pour ceux que ca interessent, et qui ne viennent pas ici pour se défouler;
j'ai résolu mon probleme, la seule réponse que j'attendais etait 'il n'est pas possible de débloquer la fonction select depuis un autre thread, par contre il semble que ca soit possible de débloquer toutes les autres fonctions bloquantes, du moins celles sur les sockets'
 
sur ce...

désolé pour vous. Il aurait peut-être fallu que je vous envoie des fleurs parce que vous faites des choses dégueulasses en ajoutant des prout prout prout, voulez-vous s'il vous plait m'excuser de vous demander pardon de vous faire remarquer que vous codez avec les pieds, prout prout prout?

il ne s'agit pas de ca, ta réponse en atteste... ce forum est une communauté d'entraide (ou bien je me trompe?), et les critiques non constructives qui sont volontairement cassantes sont tout sauf le signe de la volonté d'aider quelqu'un d'autre.
si les autres t'exasperent, reste dans ton coin, je t'ai en tout cas pas forcé a me répondre.

 
Une communauté d'entraide, soit; une maternelle, non. Lire le man, c'est la base et vous ne l'avez pas fait ou alors vous ne savez pas lire. C'est écrit explicitement que select peut se bloquer indéfiniment si on ne lui donne pas de timeout. Ne même pas prendre la peine de lire sa documentation, ça mérite des coups de pied au cul. C'est tout et si ça vous fait mal: tant mieux. La prochaine fois, vous le lirez avant de poser une question à la con et à la fin, vous n'aurez peut-être même plus besoin de poser des questions à la con pour réaliser vos projets.

c'est pas parce que tu n'as pas compris ce que je voulais faire qu'il faut etre si con. en tout cas, je t'emmerde cordialement.

bon, ça suffit les noms d'oiseaux