Le WHATWG a commencé à travailler il y a peu sur une nouvelle spécification, Web Workers. Il s'agit d'une tentative de normalisation de concepts introduits par Google Gears. Le but est de permettre à un script s'exécutant dans une page web de déclencher des traitements en tâche de fond. Cela permettra donc de faire du multithreading, d'effectuer plusieurs opération en parallèle. En effet, pour l'instant dans les navigateurs les scripts s'exécutent dans un seul thread. Tout traitement long dans une page bloque donc le navigateur. Entre autres inconvénients de cette situation, les intervalles définis dans les fonctions comme setInterval ou setTimeout ne peuvent pas être respectés.

Le brouillon de la spécification est en plein travail, mais les développeurs de Gecko ont déjà commencé à implémenter une proposition d'API. C'est du travail en cours, encore à ses balbutiements et soumis aux évolutions de la spécification, mais ça permet d'avoir une idée de ce que les navigateurs permettront de faire demain[1] Une première version devrait arriver avec Firefox 3.1, et un billet sur le blog technique de Mozilla l'évoque, mais je n'ai pas encore réussi à faire fonctionner les exemples, même avec les plus récentes compilations noctures de Shiretoko. J'ai dû louper une étape...

Principe

Le principe est similaire aux requêtes asynchrones qui ont fait le succès d'Ajax. En AJAX, on crée une requête, puis les traitements continuent, et la requête communique avec le traitement principal via des évènements. Ici, le traitement principal créera des workers qui s'exécuteront dans des threads séparés. Le programme principal et les workers communiqueront en déclenchant des évènements porteurs de messages.

La spécification définit 2 types de workers: dédiés (dedicated) et partagés (shared). Ceux-ci pourront être partagés entre plusieurs pages ouvertes à l'intérieur d'un même navigateur et communiquer avec elles. Ils seront nommés et accessibles depuis toute page ayant la même origine qu'eux (selon les mêmes règles de contrôle de l'origine qui s'appliquent aux XMLHttpRequest).

Ces fonctions de multithreading pourraient utiliser les processeurs multi-core pour accélérer les traitements: si le navigateur détecte que la machine est un quadri-core, il peut scinder un gros traitement en 4 workers qui s'exécuteront chacun sur un cœur. Et on en revient au fameux map reduce ;-)

Alors ?

Tout cela est encore bien vague, mais pourrait arriver très bientôt dans nos navigateurs. On peut donc déjà commencer à rêver de tout ce qu'on en fera. Et ça donne une raison de plus d'attendre avec impatience la prochaine version de Firefox, le navigateur qui fait pousser des tonnelles d'églantiers au dessus des pistes cyclables :-)

Notes

[1] Google étant investi dans la réflexion, on peut espérer que Gears implémentara la specification, ce qui devrait la rendre disponible dans tous les navigateurs. Par contre je me demande si elle va être implémentée nativement dans Webkit en plus de Gears, ou s'il faudra passer par Gears. Le fait que Google ait supprimé le stockage local de webkit pour le remplacer par Gears n'est pas rassurant sur ce point