Est-il nvisageable d'executer dans le même processus des appels concurrents de SELECT() ?

oui. Même sur les même descripteurs de fichiers mais je n'en vois pas l'intérêt .
 
Tu es sur ce que ce dont tu as besoin ce n'est pas plutôt un pool de thread ? un thread qui fait des select, et quand y a quelque chose à faire, il prend un thread dans le pool, lui file du travail, le lance et re ? Par exemple, quand select retourne, pour chaque fd tu lance un thread (du pool). C'est très commun comme technique

J'ai un pool de threads. Chaque thread gère une ou deux connexions. J'ai donc un select dans chaque thread qui gère un ou deux sockets. Ca parait inefficace de loin ?

non. Cela dit rien ne t'empêche de faire des IO bloquantes dans tes threads.

Les deux connexions par threads sont vraiment impérivisbles, alors je fais des appels bloquants.... apres un select(). Merci.

fais gaffe à l'usage de select. lis bien man select et man select_tut

coté serveur, j'opère la séquence suivante :
listen()
select() <- ici je place le 'listening socket' dans 'rfds'
accept()
 
J'ai l'impression que si la connexion cliente arrive dans la stack IP entre l'execution de la commande listen() et select(), le select() bloque pendant toute la durée du timeout...
 
Lorsque le client et le serveur sont interconnecté en WAN : aucun soucis. Lorsque le client et le serveur sont sur la même machine en localhost, ca foire aléatoirement.

comme le dit le man, si ton programme fonctionne uniquement grâve au timeout, le problème est ailleurs.

Je me trompe peut etre mais j'ai l'impression que select ne marche que dans les programes qui ont une forme quasi "canonique" du point de vue réseau. Des que ca se complique, faut meler threads et appels bloquants de base.

non. Que ça soit un thread ou dans un programme, l'usage est le même. Juste comme ça, tu as pensé à UDP ?

Je suis lié à une RFC pour le choix du protocole. Je suis en train de retirer l'appel SELECT en jouant sur plus de threads. J'espere obtenir un meilleur resultat...

pourquoi ? tu as de mauvais résultats avec select ?

Oui, je ne les explique pas. Ca se manifeste par des connexions bloquées sur listen(), fermées de manière intempestives, ou alors select() bloque sur son timeout alors qu'il y a de l'activité. Tout ca depend en plus du temps selon reactivité du client, et le niveau de traces. Pour le moment, je rends couable select() mais je recode pour en avoir le coeur net.

L'architecture logicielle qui consiste à donner à manger à un pool de thread apres un select() fonctionne bien. Dans mon cas, je ne peux appliquer ce schéma. Le select() n'est peut pas adapté à ma configuration (multiples select() et multiples threads).

heink ? t'es bien sur que tous tes sockets sont non-bloquants ? parce que là c'est du délire, select fonctionne au poil

Je n'ai que des socket bloquantes : listen(), accept(), send() et recv() sont bloquants. Mais je les execute suite à uen sortie de select() pour ne pas bloquer.