Comment empêcher les HTML5 Web Workers de se bloquer et de répondre correctement aux messages des parents ?

Question

J'utilise des travailleurs web pour effectuer un travail intensif au niveau du processeur, mais j'ai besoin que le travailleur réponde aux messages du script parent pendant que le travailleur est encore en cours de traitement.

Cependant, le travailleur ne répondra pas aux messages tant qu'il est bloqué dans une boucle de traitement, et je n'ai pas trouvé de moyen d'interroger la file d'attente des messages. Il semble donc que la seule solution soit d'interrompre le traitement à un certain intervalle pour permettre à tous les messages de la file d'attente d'être traités.

Les options évidentes sont d'utiliser un timer (par exemple avec setInterval), mais j'ai lu que le délai minimum entre les déclenchements est assez long ( http://ajaxian.com/archives/settimeout-delay ), ce qui est regrettable car cela ralentira considérablement le traitement.

Qu'en pensent les autres ? Je vais essayer de faire en sorte que le travailleur dispatche onmessage à lui-même à la fin de chaque onmessage et donc de mettre en œuvre une étape de la boucle de traitement par événement reçu de lui-même, mais je voulais juste voir si quelqu'un avait des idées à ce sujet.

Merci,

Answer 1

Un travailleur peut engendrer des sous-travailleurs. Le travailleur principal peut jouer le rôle de file d'attente de messages et, lorsqu'il reçoit une demande pour une opération de longue durée, créer un sous-travailleur chargé de traiter les données. Le sous-travailleur peut alors renvoyer les résultats au travailleur principal pour qu'il retire l'événement de la file d'attente et renvoie les résultats au fil d'exécution principal. De cette manière, le travailleur principal sera toujours libre d'écouter les nouveaux messages et vous aurez un contrôle total sur la file d'attente.

--Nick

Answer 2

J'ai moi-même rencontré ce problème lorsque j'ai joué avec des travailleurs pour la première fois. J'ai également envisagé d'utiliser setInterval, mais j'ai eu le sentiment que cette approche serait plutôt hasardeuse (et j'avais déjà choisi cette voie pour mon multithreading émulé). Au lieu de cela, j'ai décidé de terminer les workers à partir du thread principal (worker.terminate()) et de les recréer si la tâche dans laquelle ils sont impliqués doit être interrompue. Le ramassage des ordures, etc. semble avoir été pris en charge lors de mes tests.

Si vous souhaitez sauvegarder des données provenant de ces tâches, vous pouvez toujours les renvoyer à intervalles réguliers au fil principal pour qu'elles soient stockées. Si vous souhaitez mettre en œuvre une certaine logique pour déterminer si ces tâches sont terminées ou non, vous pouvez renvoyer les données correspondantes à intervalles suffisamment réguliers pour le permettre.

La création de sous-workers entraînerait de toute façon les mêmes problèmes ; il faudrait toujours mettre fin aux sous-workers (ou en créer de nouveaux) selon une certaine logique, et je ne suis pas sûr que cela soit aussi bien pris en charge (sur chrome, par exemple).

Jacques

Answer 3

Ayant le même problème, j'ai cherché sur le web des projets de travailleurs et j'ai trouvé quelque chose dans la rubrique Modèle de traitement section, étapes de 9 à 12. D'après ce que j'ai compris, un travailleur qui commence à traiter une tâche n'en traitera pas une autre tant que la première n'est pas terminée. Donc, si vous ne vous souciez pas d'arrêter et de reprendre une tâche, la réponse de nciagra devrait donner de meilleures performances que la reprogrammation de chaque itération de la tâche.

L'enquête se poursuit cependant.