Discussion :

[unoomad]

Bonjours à tous je voudrait savoir si il y à une difference entre un code asynchrone et non blanquant et quelle est cette difference, J'ai vu que par exemple pour un système d'upload en faisant du code non bloquant des fichiers peuvent etre transférés en parallèle, mais si j'ai bien compris on ne peut exécuté les évènements que un par un et qu'il faut attendre que la pile d'execution de cette evènement se termine pour passer à un autre évènement donc comment c'est possible de faire du parallélisme.

Désolé si je ne suis pas assez clair je donnerai plus d'explication de mon petit soucis sous demande, merci d'avance de vos réponses.

[Watilin]

Dans le jargon JavaScript, il n'y a pas de différence entre asynchrone et non bloquant. Par exemple, un appel Ajax est par défaut asynchrone, mais on peut le rendre bloquant si on passe false en 3^e paramètre à sa méthode open :

Code :

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

1
2
3
var requester = new XMLHttpRequest();
 
requester.open("GET", "example.com", false); // ouverture en mode synchrone

L'Ajax synchrone est quelque chose que je déconseille en général, car on perd tous les avantages d'Ajax.

Historiquement et par conception, JavaScript n'est exécuté que dans un seul thread (un seul « fil d'exécution » sur le processeur). Si tu appelles une ressource (requête réseau, système de fichier, etc.) en mode bloquant, le thread JavaScript est suspendu le temps que la transaction avec la ressource se termine, par exemple le temps qu'un fichier soit complètement uploadé. L'intérêt de faire des appels non bloquants, c'est que l'upload est géré par un autre thread, et JavaScript peut continuer à tourner pendant ce temps. Ça lui permet, entre autres, d'initier un autre upload de fichier.

Avec Node.js, tu as souvent le choix entre une méthode asynchrone et une autre synchrone qui fait la même chose, par exemple fs.read (asynchrone) et fs.readSync (synchrone), qui servent toutes les deux à lire un fichier.

Il y a un autre problème avec le mode bloquant en JavaScript dans les navigateurs. Du fait qu'il n'y a qu'un seul thread, et que JavaScript gère le comportement des pages web, c'est la page toute entière qui est gelée pendant toute la durée de l'appel bloquant. Un appel Ajax synchrone vers un serveur lent peut geler la page pendant plusieurs secondes, et ça rend l'utilisation du site plutôt désagréable…

Depuis quelques temps il est possible de faire du parallélisme en JavaScript grâce aux Web Workers. En gros, ils permettent de créer des threads JavaScript. J'en ai entendu parler pour la première fois grâce à David Rousset sur Developpez.com, qui présentait son excellent article qui explique bien mieux que moi tout ce que je viens de te raconter

[unoomad]

Merci de t'as réponse mais j'ai encore un soucil sur l'upload. On dit que Javascript et monothread mais que l'upload et géré par un autre thread je suis encore un peu confus sur ceci.

J'ai aussi entendu parler des Webworkers dans le libre de Nicolas Froidure j'ai pas encore eu le temps de tester ni de voir comment sa marche (au fait merci pour l'article en effet il a l'air complet).

[thelvin]

Bah JavaScript c'est JavaScript et l'upload c'est l'upload. Tu te doutes bien qu'il est pas écrit en JavaScript.

Autrement dit, JavaScript c'est le code que tu fournis dans ta page et que tu demandes à ce que le navigateur l'exécute. Et le navigateur ne dédiera qu'un thread, un seul*, pour exécuter ce code de la page.

Par contre, le code qui n'est pas JavaScript, que tu n'as pas fourni toi-même, alors ça le navigateur fait ce qu'il veut. Il fera le plus logique. En mode synchrone/bloquant, il a pas trop le choix : il exécute sur le même thread que celui dédié au JavaScript. Parce que de toute façon le thread JavaScript doit rester bloqué là jusqu'à ce que l'opération soit finie.
Mais en mode asynchrone/non-bloquant, le thread ne reste pas bloqué là à attendre la fin de l'opération, il continue le code qui suit. L'opération peut donc être confiée à un autre thread, vraisemblablement tiré du pool de threads d'IO du navigateur. Pendant ce temps-là, le thread JavaScript peut faire autre chose. Lorsque l'opération sera finie, elle devra appeler les listeners, qui sont en JavaScript et doivent être exécutés sur le thread Javascript. Les listeners devront donc attendre que le thread JavaScript soit libre, puis s'exécuter grâce à lui quand il le devient.

* Sauf, effectivement, emploi des Web Workers.

[unoomad]

Ahh je comprend merci je me doutait qu'il n'etait pas géré pas Javascript merci de vos réponses je passe le sujet en résolu.