Utilisation des web workers

Un worker dédié est seulement accessible à partir du script qui l'a préalablement créé, tandis que les workers partagés peuvent être interrogés par de multiples scripts.

Les workers s'exécutent dans un un contexte global différent du contexte de la fenêtre courante. Ainsi, utiliser le raccourci window pour obtenir le contexte global courant (au lieu de self) au sein d'un Worker retournera une erreur.

Démos basiques

Pour faciliter la prise en main des workers, nous avons réalisé quelques démos basiques de workers dédiés et partagés :

• Basic dedicated worker example (run dedicated worker) : vous autorise à entrer deux nombres qui seront multipliés ensemble. Les nombres sont envoyés à un worker, multipliés entre eux, et le résultat est renvoyé par le worker à la page pour enfin être affiché.
• Basic shared worker example (run shared worker) : très similaire, à l'exception près que deux fonctions sont disponibles et gérées par différents fichiers de script javascript : multiplying two numbers, ou squaring a number. Les deux scripts utilisent le même worker pour effectuer le calcul.

Les deux démonstrations ressemblent respectivement à ceci:

Nous allons désormais regarder les bases des workers dédiés et des workers partagés.

Dedicated workers (workers dédiés)

Comme précisé au-dessus, un worker dédié est accessible uniquement par le script qui l'a appelé. Dans cette section, nous utiliserons le JavaScript trouvé dans notre Basic dedicated worker example.

Détection de worker

Afin de mieux contrôler les erreur et la rétrocompatiblité, une bonne idée est d'envelopper votre code de worker de cette manière (main.js):

if (!!window.Worker) {

  ...

}

Instancier un dedicated worker (worker dédié)

Créer un nouveau worker est simple. Vous devez juste appeler le constructeur Worker() , en spécifiant l'URI du script à exécuter dans le thread du worker (main.js):

var myWorker = new Worker("worker.js");

Envoi de messages depuis et vers un worker dédié

La communication des workers se fait via la méthode postMessage() et le gestionnaire d'événement onmessage. Lorsque vous voulez envoyer un message au worker, vous postez des messages comme ceci ( main.js ):

first.onchange = function() {
  myWorker.postMessage([first.value,second.value]);
  console.log('Message posted to worker');
}

second.onchange = function() {
  myWorker.postMessage([first.value,second.value]);
  console.log('Message posted to worker');
}

Nous avons donc ici deux éléments <input> représentés par les variables first et second; lorsque la valeur de l'une est modifiée, myWorker.postMessage([first.value,second.value]) est utilisé pour envoyer des valeurs au worker, comme ici, un tableau. Vous pouvez envoyer tout type de message.

Dans le worker, nous pouvons répondre, lorsque le message est reçu, avec un gestionnaire d'événement comme celui-ci ( worker.js ):

onmessage = function(e) {
  console.log('Message received from main script');
  var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
  console.log('Posting message back to main script');
  postMessage(workerResult);
}

Le gestionnaire onmessage nous permet d'exécuter du code à chaque fois qu'un message est reçu, le message lui-même étant disponible  dans l'attribut data de l'évènement message. Ici, nous multiplions simplement les deux nombres ensemble et nous utilisons de nouveau postMessage() pour poster le résultat vers le thread principal.

De retour dans le thread principal, nous utilisons onmessage, pour intercepter le message envoyé par le worker:

myWorker.onmessage = function(e) {
  result.textContent = e.data;
  console.log('Message received from worker');
}

Ici, nous récupérons les données avec l'événement onmessage et avec, nous définissons l'attribut textContent du paragraphe result, afin que l'utilisateur puisse voir le résultat du calcul.

Arrêt d'un worker

Si vous avez besoin d'arrêter immédiatement un worker en cours d'exécution, vous pouvez le faire en appelant terminate():

myWorker.terminate();

Le worker est stoppé immédiatement, sans possibilité de terminer ses opérations.

Les travailleurs peuvent se fermer en appelant leur propre méthode close:

close();

Gestion des erreurs

Quand une erreur d'exécution se produit dans le worker, son gestionnaire d'événements onerror est appelé. Il reçoit un événement nommé error qui implémente l'interface ErrorEvent.

L'événement ne se propage pas et est annulable; pour empêcher l'action par défaut d'avoir lieu, le travailleur peut appeler la méthode preventDefault() .

L'événement d'erreur possède les trois domaines suivants:

message

Un message d'erreur lisible.

filename

Le nom du fichier de script dans lequel l'erreur est survenue.

lineno

Le numéro de la ligne du fichier de script sur lequel l'erreur est survenue.

Instancier des Subworkers

Un worker peut engendrer plusieurs workers. Les subworkers doivent être hébergés dans le même dossier que le parent. En outre, les URI des subworkers sont résolus par rapport à l'emplacement du worker parent. Cela rend plus facile pour les subworkers de garder une trace de leurs dépendances.

Importation de scripts et bibliothèques

Les threads de worker ont accès à une fonction globale, importScripts(), ce qui leur permet d'importer des scripts dans le même domaine que leur champ d'application. Il accepte zéro ou plusieurs URI comme paramètres de ressources pour l'importation; tous les exemples suivants sont valables:

importScripts();                        /* imports nothing */
importScripts('foo.js');                /* imports just "foo.js" */
importScripts('foo.js', 'bar.js');      /* imports two scripts */

Le navigateur charge chaque script répertorié et l'exécute. Tous les objets globaux de chaque script peuvent ensuite être utilisées par le worker. Si le script ne peut pas être chargé, NETWORK_ERROR est émit, et le code qui suit ne sera pas exécuté. Code exécuté précédemment (y compris le code reporté en utilisant window.setTimeout()) sera toujours fonctionnelle. Les déclarations de fonctions après la méthode importScripts() sont également conservés, puisque ceux-ci sont toujours évalués avant le reste du code.

Workers partagés

Un worker partagé est accessible par plusieurs scripts - y compris de différentes fenêtres, des iframes ou même d'autre workers - tant qu'ils ont la même origine. Dans cette section, nous allons discuter du code JavaScript tiré de l'exemple Basic shared worker; nous allons nous concentrer sur les différences entre les workers dédiés et partagés. Notez que dans cet exemple, nous avons deux pages HTML, chacune avec du code JavaScript appliquée qui utilise le même fichier worker.

Instancier un worker partagé

C'est la même démarche que pour un worker dédié, mais avec un nom de constructeur différent (voir index.html et index2.html ) - chacun doit déclarer le worker à l'aide du code suivant :

var myWorker = new SharedWorker("worker.js");

La grande différence réside dans la communication via un port. un port est explicitement ouvert pour que les scripts pussent communiquer avec le worker (cela se fait implicitement dans le cas des workers dédiés ). La communication doit être démarré avec start() avant que les messages puissent être affichés (voir le début des scripts multiply.js et square.js ):

myWorker.port.start();

Envoi de messages depuis et vers un worker partagé

Maintenant, les messages peuvent être envoyés au worker comme avant, mais postMessage() doit être invoquée à travers l'objet port (encore une fois, vous verrez des constructions similaires dans les scripts multiply.js et square.js ):

squareNumber.onchange = function() {
  myWorker.port.postMessage([squareNumber.value,squareNumber.value]);
  console.log('Message posted to worker');
}

Du coté worker, c'est un peu plus de complexe ( worker.js ):

onconnect = function(e) {
  var port = e.ports[0];
  port.onmessage = function(e) {
    var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
    port.postMessage(workerResult);
  }
  port.start();
}

Tout d'abord, nous utilisons le gestionnaire d'évènement onconnect qui s'active lorsque le méthode start() est invoquée. Nous utilisons l'attribut port de cet objet événement pour saisir le port et le stocker dans une variable. Ensuite, nous utilisons un gestionnaire onmessage sur le port pour faire les calculs et retourner le résultat au thread principal.

Enfin, de retour dans le script principal nous traitons le message (de nouveau, vous verrez des constructions similaires dans les scripts multiply.js et square.js ):

myWorker.port.onmessage = function(e) {
  result2.textContent = e.data[0];
  console.log('Message received from worker');
}

Quand un message revient via le port du worker, nous vérifions ce type de résultat, puis nous l'insérons dans le paragraphe résultat approprié.

Que pouvez-vous faire à un worker?

Vous pouvez utiliser les fonctions JavaScript standards dans un worker, y compris:

• Navigator
• XMLHttpRequest
• Array, Date, Math, and String
• Window.requestAnimationFrame, WindowTimers.setTimeout, and WindowTimers.setInterval

La principale chose que vous ne pouvez pas faire à partir d'un worker est d'influer directement sur la page parent. Ceci inclut la manipulation du DOM et les objets de cette page. Vous devez le faire indirectement, par l'envoi de message au script principal via DedicatedWorkerGlobalScope.postMessage, puis actionner les changements à partir de là.

A propos de la sécurité

L'interface Worker engendre des pérturbations au niveau du système d'exploitation.

Cependant, puisque les workers contrôlent soigneusement les points de communication avec d'autres threads, il est en réalité très difficile de causer des problèmes de concurrence. Il n'y a pas de moyen d'accéder aux composants non-threadées, ou au DOM.

Spécifications

Navigateur compatible

Note navigateur

• Chrome/Opéra donne une erreur "Uncaught SecurityError: Failed to construct 'Worker': Script at 'file:///Path/to/worker.js' cannot be accessed from origin 'null'.." lorsque vous essayez d'exécuter un worker local. Il doit être sur un domaine propre.
• Pour Safari 7.1.2, vous pouvez appeler console.log à partir d'un worker, mais il ne sera inactif. Les anciennes versions de Safari ne vous permettent pas d'appeler console.log à partir d'un worker.

Voir aussi

• interface Worker
• interface SharedWorker
• Functions available to workers
• Advanced concepts and examples