Confus, les langages sont-ils comme le python, Ruby Single Thread? contrairement à dire java? (pour les applications Web)
Je lisais comment Clojure est 'cool' à cause de sa syntaxe +, il tourne sur la JVM donc il est multithread etc. etc.
Les langues comme Ruby et Python sont-elles alors threadées dans la nature? (lors de l'exécution en tant qu'application Web).
Quelles sont les différences sous-jacentes entre python/Ruby et Java s'exécutant sur tomcat?
Le serveur Web ne dispose-t-il pas d'un pool de threads dans tous les cas?
Python et Ruby prennent entièrement en charge le multi-threading. Certaines implémentations (par exemple, CPython, MRI, YARV) ne peuvent pas exécuter de threads en parallèle, mais il s’agit d’une limitation de ces implémentations spécifiques, et non du langage. Ceci est similaire à Java, où il existe également des implémentations qui ne peuvent pas exécuter de threads en parallèle, mais cela ne signifie pas que Java est mono-threadé.
Notez que dans les deux cas, il existe de nombreuses implémentations qui can peuvent exécuter des threads en parallèle: PyPy, IronPython, Jython, IronRuby et JRuby ne sont que quelques exemples.
La principale différence entre Clojure d'un côté et Python, Ruby, Java, C #, C++, C, PHP et à peu près tous les autres langages grand public et non conventionnels de l'autre côté est que Clojure a un modèle de concurrence/ sane . Tous les autres langages utilisent des threads, que nous avons connus pour être un mauvais modèle de concurrence depuis au moins 40 ans. Clojure OTOH a un modèle de mise à jour sain qui lui permet non seulement de présenter un, mais en réalité, plusieurs modèles de simultanéité sains au programmeur: mises à jour atomiques, mémoire transactionnelle logicielle, agents asynchrones, variables globales locales à threads locales, contrats à terme, promesses, concurrence des flux de données et à l'avenir peut-être même plus.
CPython a un Global Interpreter Lock qui peut réduire les performances du code multithread en Python. Dans certains cas, l’effet final est que les threads ne peuvent pas s’exécuter simultanément à cause d’un conflit de verrouillage. Toutes les implémentations Python n'utilisent pas GIL, ce qui peut ne pas s'appliquer à JPython, IronPython ou à d'autres implémentations.
Le langage lui-même prend en charge les threads et autres opérations asynchrones. Les bibliothèques Python peuvent également prendre en charge le threading en interne sans l'exposer directement à l'interpréteur Python.
Si vous avez entendu quelque chose de négatif à propos de Python et du threading (ou que cela ne le supporte pas), c'est probablement quelqu'un qui rencontre une situation où le GIL est à l'origine d'un goulot d'étranglement.
Une question confuse avec beaucoup de réponses confuses ...
Tout d'abord, le threading et l'exécution simultanée sont des choses différentes. Python supporte les threads très bien; il ne prend pas en charge l'exécution simultanée dans les mises en œuvre réelles. (Dans toutes les mises en œuvre sérieuses, un seul thread VM peut être exécuté à la fois; les nombreuses tentatives de découplage des threads VM ont toutes échoué.)
Deuxièmement, cela n’est pas pertinent pour les applications Web. Vous n'avez pas besoin que les moteurs Python s'exécutent simultanément dans le même processus . Vous créez separent processus pour chaque serveur, lequel peut ensuite traiter les demandes en parallèle car elles ne sont pas liées du tout.
L'utilisation de threads pour les sites Web est une mauvaise idée. Pourquoi introduire les dangers du filetage - verrouillage, conditions de concurrence, impasses - à quelque chose de fondamentalement embarrassant par nature? Il est bien plus prudent de placer chaque serveur dans son propre processus isolé, en évitant le risque de tous ces problèmes.
(Il y a des avantages à partager l'espace mémoire - cela économise de la mémoire, en partageant du code statique - mais cela peut être résolu sans thread.)
Le serveur Web aura certainement un pool de threads. C'est seulement en dehors du contrôle de votre programme. Ces threads sont utilisés pour gérer les requêtes HTTP. Chaque demande HTTP est traitée dans un thread séparé et le thread est libéré pour le pool lorsque la réponse HTTP associée est terminée. Si le serveur Web ne dispose pas d'un tel pool, le service aurait été extrêmement lent.
Que le langage de programmation soit mono ou multithread dépend de la possibilité de générer par programmation new des threads en utilisant le langage en question. Si cela n'est pas possible, la langue est alors en lecture seule, par exemple PHP. Autant que je sache, Ruby et Python prennent en charge le multithreading.
La plupart des langues ne définissent pas le single ou le multithreading. Habituellement, il appartient aux bibliothèques de les implémenter.
Cela étant dit, certaines langues s'y prêtent mieux que d'autres. CPython, par exemple, a des problèmes de verrouillage d'interprète lors du multithreading, contrairement à Jython (Python s'exécutant sur la JVM).
Une partie du pouvoir réel de Clojure (IMO) réside dans le fait qu’il s’exécute sur la JVM. Vous bénéficiez de multithreading et de tonnes de bibliothèques gratuitement.
La réponse courte est oui, ils sont à thread unique.
La réponse longue est que cela dépend.
JRuby est multithread et peut être exécuté dans Tomcat comme tout autre code Java. MRI (par défaut Ruby) et Python ont tous deux un verrou d'interpréteur global (GIL) et sont donc à thread unique.
La manière dont cela fonctionne pour les serveurs Web est encore compliquée par le nombre de configurations de serveur disponibles. Pour la plupart des applications Ruby, il existe (au moins) deux niveaux de serveurs, un serveur de fichiers proxy/statique comme nginx, puis le serveur d'applications Ruby.
Nginx n'utilise pas de threads comme Apache ou Tomcat, il utilise des événements non bloquants (et je pense que les processus de travail fourchus). Cela lui permet de gérer des niveaux de concurrence plus élevés que ne le permettraient les surcoûts et inefficacités de planification des threads natifs.
Les différents serveurs d'applications Ruby fonctionnent également de différentes manières pour obtenir un débit élevé et une concurrence sans thread. Thin utilise libev et le modèle à événement asynchrone comme Nginx. Mongrel utilise un pool circulaire de processus de travail. Unicorn utilise Unix natif IPC (sélectionné sur un socket) pour équilibrer le chargement d'un groupe de processus en mode fourchu via un socket proxy principal.
Les threads ne sont qu'un moyen de résoudre le problème de la concurrence. Les processus multiples et les modèles événementiels constituent une approche différente qui cadre bien avec la base Unix. Ceci est fondamentalement différent de la manière dont Java traite le monde.
Quelques langages de programmation interprétés, tels que CPython et Ruby, prennent en charge le threading, mais ont une limitation appelée GIL (Global Interpreter Lock). GIL est un verrou d'exclusion mutuelle détenu par l'interprète qui empêche l'interprète d'interpréter simultanément le code des applications sur deux ou plusieurs threads en même temps, ce qui limite efficacement l'accès simultané sur plusieurs systèmes centraux.
de wikipedia Fil de discussion
En lisant ces réponses ici ... Beaucoup d’entre eux essaient de paraître plus intelligents qu’ils ne le sont vraiment à mon humble avis (je parle surtout de choses liées à Ruby comme celle que je connais le mieux). En fait, JRuby est actuellement la seule implémentation Ruby qui prend en charge la concurrence réelle. Sur la JVM, les threads Ruby sont mappés sur les threads natifs du système d’exploitation, sans interférence de GIL. Il est donc tout à fait correct de dire que Ruby n'est pas multithread. Dans la version 1.8.x, Ruby est exécuté à l’intérieur d’un seul thread de système d’exploitation, et bien que vous ayez l’impression fausse de concomitance avec des threads verts, GIL vous empêchera en réalité d’avoir une véritable concurrence. Dans Ruby 1.9, cela a un peu changé, puisqu’à présent, un processus Ruby peut être associé à de nombreux threads de système d’exploitation (plus les threads verts), mais encore une fois, GIL détruira totalement le point et deviendra le goulot d’étranglement.
En pratique, du point de vue habituel d'une application Web, il ne devrait pas avoir beaucoup d'importance si son fonctionnement est unique ou multithread. De toute façon, le problème se pose surtout du côté serveur et il s’agit essentiellement d’une différence de technique d’échelle.
Python
Laissez-moi essayer de le dire plus simplement que les réponses plus détaillées.
Le cœur de la réponse ici n’a pas vraiment à voir avec Python étant mono-threadé ou multi-threadé. Cela a plus à voir avec le threading que le multitraitement.
Dire que Python est "single-threaded" ne capture pas vraiment la réalité, car vous pouvez avoir plusieurs threads en cours d'exécution dans un processus Python. Utilisez simplement la bibliothèque de threads et créez plusieurs threads. Là, vous venez de prouver que Python n’est pas à thread unique.
Mais utiliser plusieurs threads en Python ne signifie PAS que vous utilisez plusieurs processeurs simultanément. En fait, le verrou d'interprète global empêche cela. C'est donc là que les questions se posent.
Fondamentalement, le threading en Python ne peut pas être utilisé pour un calcul de CPU parallèle. Mais vous POUVEZ effectuer un calcul de processeur parallèle avec Python en utilisant multitraitement _ au lieu de multi-threading_.
J'ai trouvé cet article très utile lors de mes recherches: https://timber.io/blog/multiprocessing-vs-multithreading-in-python-what-you-need-tknow . Il comprend des exemples concrets du moment où vous souhaitez utiliser le multitraitement par rapport au multithreading.
Oui, Ruby et Python peuvent gérer le multi-threading, mais dans de nombreux cas (Web), il est préférable de s’appuyer sur les threads générés par les demandes http du client au serveur. Même si vous générez plusieurs threads sur une même application pour réduire les coûts d’exécution ou gérer plusieurs tâches à la fois, dans le cas d’une application Web prenant généralement trop de temps, personne n’attendra avec joie plus d’une fraction de seconde la réponse de Dans votre application sur une seule page, il est plus judicieux d'utiliser les techniques AJAX (JavaScript et XML asynchrones): assurez-vous que la conception de votre site Web s'affiche rapidement et effectuez une insertion asynchrone de ces éléments codés en dur ultérieurement. .
Cela ne signifie pas que le multi-threading est inutile pour le web! Il est fortement recommandé de réduire la charge de votre serveur si vous souhaitez exécuter des applications récursives-compliquées-hardcore (pas pour un site Web, je veux dire), mais ce que ce retour doit aboutir dans des fichiers ou dans des bases de données, vous pouvez donc le faire doucement. servi par une réponse http.
Ruby
L'interpréteur Ruby est à thread unique, ce qui signifie que plusieurs de ses méthodes ne sont pas thread-safe.
Dans le monde Rails, ce thread unique a été principalement envoyé au serveur. Ainsi, vous verrez que nginx s’exécute avec un pool de serveurs bâtons, chacun ayant un interpréteur en mémoire, traite une requête à la fois et dans son propre thread.
Passenger, running "Ruby enterprise" apporte le concept de ramassage des ordures et un peu de sécurité des fils dans Rails, et c’est beau.
Il reste encore du travail à faire dans Rails dans ce domaine, mais cela avance lentement - mais en général, l’idée est d’avoir plusieurs services et serveurs.
Comment démêler les nœuds dans tous ces fils ...
Clojure n'a pas inventé le threading, mais il est particulièrement bien supporté avec la mémoire transactionnelle logicielle, les atomes, les agents, les opérations de carte parallèle, ...
Tous les autres ont accumulé le support de threading. Ruby est un cas particulier, car certaines implémentations ont des threads verts qui sont une sorte de threads émulés par logiciel et n'utilisent pas tous les cœurs. 1.9 mettra cela au repos.
En ce qui concerne les serveurs Web, non, ils ne fonctionnent pas toujours en multithread, Apache s’est traditionnellement déroulé comme un groupe de démons, qui constituent un pool de processus séparés à thread unique. Actuellement, il y a plus d'options pour exécuter les serveurs Apache.
Pour résumer toutes les langues modernes, prenez en charge le threading sous une forme ou une autre.
Les langages plus récents tels que scala et clojure ajoutent un support spécifique pour améliorer le travail avec plusieurs threads sans verrouillage explicite, ce qui est traditionnellement le grand piège du multithreading.