API Web Workers
===============

Les **Web Workers** sont un mécanisme grâce auquel les instructions d'un script peuvent être exécutés dans un thread en arrière-plan séparé du thread d'exécution principal d'une application web. Cela a pour avantage qu'un traitement laborieux peut être réalisé dans un thread séparé, permettant au thread principal (généralement l'interface utilisateur) de fonctionner sans blocage ni ralentissement.

Concepts et utilisation des Web Workers
---------------------------------------

Un worker est un objet créé en utilisant un constructeur (e.g. `Worker()`) qui exécute un fichier JavaScript nommé — ce fichier contient le code que doit exécuter le thread du worker; les workers s'exécutent dans un autre contexte global qui est différent du contexte actuel `window`. Ce contexte est représenté par un objet `DedicatedWorkerGlobalScope` dans le cas des workers dédiés (workers standards utilisés par un script unique; les workers partagés utilisent `SharedWorkerGlobalScope` (en-US)).

Vous pouvez exécuter quelque code que ce soit à l'intérieur du thread du worker, avec quelques exceptions cependant. Par exemple, vous ne pouvez pas directement manipuler le DOM à partir d'un worker, ou utiliser des méthodes et des propriétés par défaut de l'objet `window`. Mais vous pouvez utiliser un grand nombre des éléments disponibles sous `window`, comprenant les WebSockets, et les mécanismes de stockage de données tels qu'IndexedDB et l'API Data Store spécifique à Firefox OS. Consultez Les fonctions et classes accessibles aux workers pour plus de détails.

Les données sont envoyées entre les workers et le thread principal au moyen d'un sytème de messages — des deux côtés les messages sont envoyés en utilisant la méthode `postMessage()`, et la réponse leur parvient au moyen du gestionnaire d'événement `onmessage` (le message est contenu dans l'attribut `data` de l'événement `message`.) Les données sont copiées plutôt que partagées.

Les workers peuvent à leur tour engendrer de nouveaux workers, aussi longtemps que ces workers partagent la même origine que la page parente. De plus, les workers peuvent utiliser `XMLHttpRequest` pour les E/S réseau, à l'exception que les attributs `responseXML` et `channel` de `XMLHttpRequest` retournent toujours `null`.

En plus des workers dédiés, il y a d'autres types de worker :

* Les workers partagés sont des workers qui peuvent être utilisés par de multiples scripts s'exécutant dans différentes fenêtres, IFrames, etc., aussi longtemps qu'ils sont dans le même domaine que le worker. Leur fonctionnement est un petit plus complexe que les workers dédiés — les scripts doivent communiquer via un port actif. Consultez `SharedWorker` pour plus de détails.
* Les ServiceWorkers (en-US) fonctionnent essentiellement comme des serveurs proxy placés entre des applications web, et le navigateur et le réseau (lorsque disponibles). Ils sont destinés (entre autres choses) à permettre la création de véritables expériences déconnectées, interceptant les requêtes du réseau et prenant des décisions appropriées en fonction de la disponibilité du réseau et de la mise à jours des ressources situées sur le serveur. Ils permettront aussi d'accéder à des notifications poussées (push) et à des APIs synchronisées en arrière-plan.
* Les Workers Chrome sont un type de worker spécifique à Firefox que vous pouvez utiliser si vous développez des extensions et que vous voulez y utiliser des workers et avoir accès aux js-ctypes dans votre worker. Consulter `ChromeWorker` pour plus de détails.
* Les Audio Workers donne la possibilité d'effectuer directement dans le contexte d'un worker web un traitement audio scripté.

**Note :** Selon les Spécifications de Web Worker, les erreurs dans les workers ne devraient pas déborder (voir bug Firefox 1188141). Cela a été implémenté dans Firefox 42.

Les interfaces Web Worker
-------------------------

`AbstractWorker`

Propriétés et méthodes abstraites communes à tous les types de workers (i.e. `Worker` ou `SharedWorker`).

`Worker`

Représente le thread d'un worker en cours d'exécution, vous permettant de passer des messages au code du worker en cours d'exécution.

`WorkerLocation`

Défini la localisation du scripte exécuté par le Worker.

`SharedWorker`

Représente un type spécifique de worker qui peut être *accédé* à partir de plusieurs contextes de navigation, à savoir plusieurs fenêtres, iframes ou même workers.

`WorkerGlobalScope`

Représente le contexte générique de tout worker (il joue le même rôle que `Window` pour un contenu web normal). Les différents types de worker ont un contexte d'objets qui hérite de cette interface et ajoute des fonctionnalités supplémentaires.

`DedicatedWorkerGlobalScope`

Représente le contexte d'un worker dédié, héritant de `WorkerGlobalScope` et ajoutant des fonctionnalités spécifiques.

`SharedWorkerGlobalScope` (en-US)

Représente le contexte d'un worker partagé, héritant de `WorkerGlobalScope` et ajoutant des fonctionnalités spécifiques.

`WorkerNavigator` (en-US)

Représente l'identité et l'état de l'agent utilisateur (le client):

Exemples
--------

Nous avons créé deux simples démos pour illustrer des usages basiques :

* Exemple basique d'un worker dédié (lancer le worker dédié).
* Exemple basique d'un worker partagé (lancer le worker partagé).

Vous pouvez obtenir plus d'informations sur le fonctionnement de ces démos dans notre guide d'utilisation des web workers.

Spécifications
--------------

| Specification |
| --- |
| HTML Standard # workers |

Voir aussi
----------

* Utilisation des web workers
* L'interface Worker
* L'interface SharedWorker
* L'API ServiceWorker (en-US)
* Les fonctions et classes accessibles aux workers
* ChromeWorker : pour l'utilisation des workers dans un code privilégié (chrome)