Discussion :

[nicknolt]

Bien le bonjour a tous!

On dit que le probleme dans les sockets synchrones et que les fonctions dont ils disposent sont bloquantes.

Par exemple pour la connection d'un client sur un serveur doit attendre qu'un client soit connecté avant de pouvoir traiter la connection d'un autre client.

Le mode asynchrone quant a lui utilise un pool de thread et permet de passer la main tout de suite a l'application serveur.

Ma question est : "N'est il pas possible d'utiliser le mode synchrone avec des threads (et pourquoi pas pour les methodes de rappels un delegué) pour obtenir le meme resultats qu'avec le mode asynchrone? Et sinon, quel est le reel avantage du mode asynchrone?"

Merci

[Johan31]

Pour comparaison le mode synchrone c'est le téléphone et le mode asynchrone c'est La Poste.

Par exemple pour la connection d'un client sur un serveur doit attendre qu'un client soit connecté avant de pouvoir traiter la connection d'un autre client

Non ce n'est pas ca, justement en applicant les threads tu peux traiter plusieurs clients en même temps. La différence l'attente d 'une réponse. Si je me souviens bien

Donc pour répondre à ta question oui on peut faire du synchrone avec des threads pour traiter plusieurs clients en même temps.

[nicknolt]

Oui je sais bien puisque j'ai deja fais un chat en mode synchrone et avant d'en faire un en mode asynchrone je voulais savoir si cela apporterait vraiment un plus.

Et en effet tu as tout a fais raison, j'ai fais de la lecture aujourd'hui et il est vrai que les threads du pool du CLR sont optimisés par rapport aux threads classiques (cependant il ne peut y en avoir que 25 au meme moment).

Merci bien pour ta reponse

[abelman]

cependant il ne peut y en avoir que 25 au meme moment.

Oui mais cela ne les empêche pas de traiter efficacement les requêtes. La logique n'est pas un thread pour un client mais plutot une queue de requêtes qui sont traités par les threads du pool.
<mode très avancé>
Par ailleurs tu peux te faire ton propre pool de thread si tu ne veux pas être limité au 25 thread.
Une autre limitation que je trouve au Pool de thread de .NET, est que tu ne peux pas décider d'arrêter les threads du pool, ou même savoir quand ils sont terminés
</mode très avancé>

[nicknolt]

Ah il sait tout cet abelman!

J'ai lu effectivement (Smacchia) que les requetes données a ce pool ne peuvent pas etre retirées et que ces threads sont Background(ne sont obligés de se finir avant la fin du prog principal) et que les mecanismes de synchronisations ne peuvent pas marcher avec ceux ci car l'objet de synchro ne se declare qu'apres la fin du traitement asynchrone.

Pour s'assurer que les requetes du pool de threads soient finies ils faut utiliser des ruses a base d'evenements

Maintenant je comprend mieux tout ce bazar!

Et donc les requetes sont distribués entre chaque thread du pool et donc c'est pas un thread par client comme un thread classique.

Bon et bien ca c'est quand meme important d'avoir saisi tout ces subtilitées.

Merci tout le monde et que le YOGAT FLAMME soit avec toi abelman