Fonctions Bloquantes Et Fonctions Asynchrones En Javascript - Yoctopuce Yocto-3D-V2 Mode D'emploi

15. Utilisation du Yocto-3D-V2 en JavaScript / EcmaScript
15.1. Fonctions bloquantes et fonctions asynchrones en
JavaScript
JavaScript a été conçu pour éviter toute situation de concurrence durant l'exécution. Il n'y a jamais
qu'un seul thread en JavaScript. Cela signifie que si un programme effectue une attente active
durant une communication réseau, par exemple pour lire un capteur, le programme entier se trouve
bloqué. Dans un navigateur, cela peut se traduire par un blocage complet de l'interface utilisateur.
C'est pourquoi l'utilisation de fonctions d'entrée/sortie bloquantes en JavaScript est sévèrement
découragée de nos jours, et les API bloquantes se font toutes déclarer deprecated.
Plutôt que d'utiliser des threads parallèles, JavaScript utilise les opérations asynchrones pour gérer
les attentes dans les entrées/sorties: lorsqu'une fonction potentiellement bloquante doit être appelée,
l'opération est uniquement déclenchée mais le flot d'exécution est immédiatement terminé. La
moteur JavaScript est alors libre pour exécuter d'autres tâches, comme la gestion de l'interface
utilisateur par exemple. Lorsque l'opération bloquante se termine finalement, le système relance le
code en appelant une fonction de callback, en passant en paramètre le résultat de l'opération, pour
permettre de continuer la tâche originale.
Lorsqu'on les utilises avec des simples fonctions de callback, comme c'est fait quasi
systématiquement dans les librairies Node.js, les opérations asynchrones ont la fâcheuse tendance
de rentre le code illisible puisqu'elles découpent systématiquement le flot du code en petites
fonctions de callback déconnectées les unes des autres. Heureusement, de nouvelles idées sont
apparues récemment pour améliorer la situation. En particulier, l'utilisation d'objets Promise pour
travailler avec les opérations asynchrones aide beaucoup. N'importe quelle fonction qui effectue une
opération potentiellement longue peut retourner une promesse de se terminer, et cet objet Promise
peut être utilisé par l'appelant pour chaîner d'autres opérations en un flot d'exécution. La classe
Promise fait partie du standard EcmaScript 2015.
Les objets Promise sont utiles, mais ce qui les rend vraiment pratique est la nouvelle syntaxe
/ pour la gestion des appels asynchrones:
async await
• une fonction déclarée async encapsule automatiquement son résultat dans une promesse
• dans une fonction async, tout appel préfixé par await a pour effet de chaîner automatiquement
la promesses retournées par la fonction appelée à une promesse de continue l'exécution de
l'appelant
• tout exception durant l'exécution d'une fonction async déclenche le flot de traitrment d'erreur
de la promesse.
En clair, async et await permettent d'écrire du code EcmaScript avec tous les avantages des
entrées/sorties asynchrones, mais sans interrompre le flot d'écriture du code. Cela revient quasiment
à une exécution multi-tâche, mais en garantissant que le passage de contrôle d'une tâche à l'autre
ne se produira que là où le mot-clé await apparaît.
Nous avons donc décidé d'écrire cette nouvelle librairie EcmaScript en utilisant les objets Promise et
des fonctions async, pour vous permettre d'utiliser la notation await si pratique. Et pour ne pas devoir
vous poser la question pour chaque méthode de savoir si elle est asynchrone ou pas, la convention
est la suivante: toutes les méthodes publiques de la librairie EcmaScript sont async, c'est-à-dire
qu'elles retournent un objet Promise, sauf:
•
GetTickCount()
de sens...
•
FindModule()
l'énumération des modules est faite en tâche de fond sur des structures internes qui sont
gérées de manière transparente, et qu'il n'est donc pas nécessaire de faire des opérations
bloquantes durant le simple parcours de ces listes de modules.
114
, parce que mesurer le temps de manière asynchrone n'a pas beaucoup
, ,
FirstModule()
, ... parce que la détection et
nextModule()
www.yoctopuce.com