Multithreading JavaScript

10

Eh bien, de nos jours, JavaScript est le principal acteur de toutes les technologies de développement Web, côté client pour améliorer l'interface utilisateur, logique côté client, sur certains serveurs Web comme logique côté serveur également

Ajoutez à cela le fait que les gens (au moins certains d'entre eux) ont commencé à évoluer dans le développement de jeux Web du flash au javascript et au HTML5

N'est-il pas temps qu'il prenne en charge le multi-threading! Existe-t-il des navigateurs qui permettent à JavaScript d'être multi-thread ou existe-t-il dans des standards, HTML5 ou versions futures?!

web-development javascript web-applications web Ali
la source
1
Les gens ne font pas des choses qui ne sont pas nécessaires. Les personnes qui ont contribué à la conception de Javascript sont également celles qui sont liées aux serveurs Web et aux navigateurs en cours de développement afin de le savoir. C'est une question d'utilité.
Dipan Mehta

Réponses:

9

Le multi-threading ne sera pas effectué en EcmaScript mais peut être exposé dans des environnements hôtes.

Les exemples classiques sont WebWorkers qui vous permet de faire tourner un travailleur en arrière-plan pour travailler et abuser de <iframe>'s afin de générer de nouveaux processus.

Il convient de noter que le multi-threading en JavaScript n'est pas nécessaire (il existe des exceptions, principalement des programmes liés aux graphiques). Vous n'avez pas besoin de plusieurs threads, vous avez déjà une boucle d'événement pour votre interface graphique et votre rendu graphique (canevas) est accéléré par le matériel (ce qui signifie que le GPU rend vos graphiques en parallèle pour vous).

Bien que des projets comme webcl soient assez excitants.

Raynos
la source
2
Pouvez-vous développer le fait que cela "n'est pas nécessaire"? J'ai rencontré récemment une instance où le cas naturel de la programmation de bureau serait de générer un thread pour gérer la tâche, mais ce n'était évidemment pas une option facile ou standard. J'ai travaillé autour de cette affaire, mais la génération d'un fil semblait être la solution la plus élégante.
Rig
@rig quel était le cas que vous essayiez de gérer?
Zachary K
@Rig donne un exemple concret. le traitement coûteux en calcul est rare dans le JavaScript côté client
Raynos
@Raynos veuillez expliquer plus en détail comment cela n'est pas nécessaire, je pense seulement que je ne suis pas sûr que dans le développement de jeux par exemple s'il y a un calcul lourd sur les graphiques et sur la physique et la fréquence d'images logique sera facilement affectée si aucun multithreading n'est là je pense
Ali
@Ali, je suis sorti et j'ai dit qu'il y avait des exceptions. Cependant, la plupart de ces calculs lourds devraient être donnés au GPU via l'API graphique accélérée matériellement
Raynos
4

NON

Le multi-threading est l'une des choses les plus difficiles à résoudre dans les logiciels. Il y a beaucoup trop de cas d'angle qui sont vraiment difficiles à résoudre lorsque votre code n'est pas déterministe. (Je parle de multi-threading avec des verrous, etc.). De plus, toutes les différentes bibliothèques JavaScript sont basées sur l'hypothèse qu'il n'est pas multi-thread.

Cela étant dit, il existe des travailleurs Web qui vous offrent un cadre basé sur les acteurs pour effectuer des opérations de type multi-traitement. Vous pouvez créer des employés et transmettre des données dans les deux sens via des événements.

EDIT: L'autre raison est que lorsque JavaScript a été créé, cela a été fait avec l'hypothèse qu'il serait utilisé pour de petites tâches, donc aucune concurrence n'a été intégrée. Pour le moderniser, il casserait beaucoup de code. En ajoutant des travailleurs Web, il a été possible d'avoir un système où il y a concurrence sans mémoire partagée, mais en utilisant des acteurs, un modèle de concurrence qui s'est révélé très robuste dans un certain nombre d'autres langues comme Erlang, Scala, Clojure etc.

(SI vous ne pouvez pas dire que je n'aime pas vraiment la concurrence basée sur le verrouillage)

Zachary K
la source
1
Multi threading is one of the hardest things in software to get right.- j'ai juste été surpris par ça! Le navigateur que vous utilisez, le système d'exploitation de votre bureau, le serveur Web qui dessert cette page - pratiquement chaque application que vous utilisez quotidiennement est multithread. ÊTES-VOUS SÛR DE LE SIGNIFIER? Pourtant, pour vous dévaloriser, mais je le ferai si vous ditesmultithreading is not done because it is hard
Dipan Mehta
3
@DipanMehta multi threading est l' une des choses les plus difficiles dans le logiciel à bien faire. La raison pour laquelle toutes ces applications l'utilisent, c'est parce qu'elles sont écrites par des gens vraiment talentueux
Raynos
@Raynos - mon Dieu! Vous m'appelez donc talentueux! Je l'utilise tous les jours ... je pense que lorsque vous êtes en programmation C ou n'importe quelle application à grande échelle, c'est assez courant. Le fait est que, indépendamment de l'utilisation et des exigences, le consortium W3C ne l'a pas vraiment épargné pour Javascript car c'était trop dur !
Dipan Mehta
2
Vous sous-estimez à quel point il est difficile d'écrire des programmes parallèles corrects et efficaces. Mais le multi threading n'est pas en JavaScript car sa complexité inutile (la chose a été écrite en 3 semaines)
Raynos
2
@DipanMehta obtenir une concurrence basée sur un verrou correctement, et clouer tous les cas de coin est un problème difficile. Par exemple, une implémentation de quelque chose d'aussi simple qu'une file d'attente avec des verrous qui peut être prouvée dans tous les cas aurait été un résultat publiable jusqu'à il y a quelques années. Mais plus important encore, essayer de mettre cela à niveau dans une langue qui ne l'a pas fait, c'est demander des ennuis.
Zachary K
3

ouvrir javascript pour le multithreading créera plus de problèmes qu'il n'en résout:

l'architecture actuelle est basée sur des événements à un seul thread (s'exécutant le plus souvent dans le thread gui) en d'autres termes, avec chaque bloc de code, vous pouvez être assuré que rien dans l'environnement ne changera du début à la fin, sauf ce qui est changé dans le code.

dès que vous autorisez la préemption ou l'exécution parallèle, cette fonctionnalité disparaîtra, cela signifie que vous devez appliquer des verrous aux données que vous souhaitez muter et avoir des conditions de concurrence difficile à déboguer pour éviter

il est possible d'avoir une exécution pseudo-parallèle en utilisant des délais d'attente, cela signifie diviser les fonctions de grande ou longue durée en morceaux atomiques et les utiliser setTimeout(function(){nextstep(args);},1);pour que d'autres choses puissent s'exécuter si nécessaire

monstre à cliquet
la source
0

Intel a publié River Trail il y a quelque temps, ce qui permet une programmation parallèle en Javascript. Cependant, c'est un plugin Firefox uniquement et je n'ai pas entendu parler d'une feuille de route qui intègre cette technologie au W3C, et encore moins à l'ECMA.

Demian Brecht
la source