Confundido, ¿hay idiomas como python, ruby ​​single threaded? a diferencia de decir java? (Para aplicaciones web)

Question

estaba leyendo cómo Clojure es 'cool' debido a su sintaxis + se ejecuta en la JVM por lo que es multiproceso, etc, etc

son lenguajes como Ruby y Python sola rosca en la naturaleza, entonces? (cuando se ejecuta como una aplicación web).

¿Cuáles son las diferencias subyacentes entre python/ruby ​​y decir que java se ejecuta en tomcat?

¿El servidor web no tiene un conjunto de hilos para trabajar en todos los casos?

Answer 1

Tanto Python como Ruby son totalmente compatibles con multi-threading. Hay algunas implementaciones (por ejemplo, CPython, MRI, YARV) que no pueden ejecutar subprocesos en paralelo, pero eso es una limitación de esas implementaciones específicas, no del lenguaje. Esto es similar a Java, donde también hay algunas implementaciones que no pueden ejecutar subprocesos en paralelo, pero eso no significa que Java tenga un solo subproceso.

Nótese que en ambos casos hay un montón de implementaciones, que puede hilos en paralelos: PyPy, IronPython, Jython, IronRuby y JRuby son solamente algunos de los ejemplos.

La principal diferencia entre Clojure por un lado y Python, Ruby, Java, C#, C++, C, PHP y casi todos los demás mainstream y el lenguaje no tan dominante en el otro lado es que Clojure tiene un sane modelo de concurrencia. Todos los demás lenguajes utilizan subprocesos, que hemos conocido como un modelo de mala concurrencia durante al menos 40 años. Clojure OTOH tiene un modelo de actualización que le permite no solo presentar al programador uno, sino múltiples modelos de simultaneidad: actualizaciones atómicas, memoria transaccional de software, agentes asíncronos, variables globales localizadas por thread de concordancia, futuros, promesas, concurrencia de flujo de datos y en el futuro posiblemente aún más.

Answer 2

Ciertamente, el servidor web tendrá un conjunto de hilos. Eso solo está fuera del control de tu programa. Esos hilos se usan para manejar solicitudes HTTP. Cada solicitud HTTP se maneja en un subproceso separado y el subproceso se devuelve al grupo cuando finaliza la respuesta HTTP asociada. Si el servidor web no tiene ese grupo, hubiera sido extremadamente lento en la prestación.

Si un lenguaje de programación es singlethreaded o multiproceso depende de la posibilidad de generar programáticamente hilos nuevos utilizando el idioma en cuestión. Si eso no es posible, entonces el lenguaje es singlethreaded, por ejemplo PHP. Por lo que puedo ver, tanto Ruby como Python admiten multihilo.

Answer 3

La mayoría de los lenguajes no definen sola o multihebra. Por lo general, eso queda en manos de las bibliotecas para implementarlo.

Dicho esto, algunos idiomas son mejores que otros. CPython, por ejemplo, tiene problemas con el bloqueo de intérpretes durante el subprocesamiento múltiple, Jython (Python ejecutándose en la JVM) no lo hace.

Parte de la potencia real de Clojure (IMO) es que se ejecuta en la JVM. Obtiene multiprocesamiento y toneladas de bibliotecas de forma gratuita.

Answer 4

Rubí

The Ruby intérprete es roscado único, es decir, que varios de sus métodos no es seguro para subprocesos.

En el mundo de los rieles, este hilo único se ha enviado principalmente al servidor. Por lo tanto, verá que nginx se está ejecutando con un grupo de servidores mongrel, cada uno de los cuales tiene un intérprete en la memoria, procesa 1 solicitud a la vez y en su propio hilo.

Pasajero, corriendo "ruby enterprise" trae el concepto de recolección de basura y algo de seguridad de hilos en Rails, y es agradable.

Todavía hay trabajo por hacer en Rails en esta área, pero está llegando lentamente, pero en general, la idea es tener múltiples servicios y servidores.

Answer 5

Cómo desenredar los nudos en al esos hilos ...

Clojure no inventó roscado, sin embargo, tiene particularmente fuerte apoyo a la misma con el software transaccional memoria, Átomos, agentes, operaciones de correlación paralelos, ...

Todos los demás han acumulado soporte de enhebrado. Ruby es un caso especial, ya que tiene hilos verdes en algunas implementaciones que son un tipo de subprocesos de software emulado y no usan todos los núcleos. 1.9 pondrá esto a descansar.

En cuanto a los servidores web, no siempre funcionan en multiproceso, apache se ha ejecutado tradicionalmente como una bandada de daemons que son un conjunto de procesos de un único subproceso. Ahora, actualmente, hay más opciones para ejecutar servidores apache.

Para resumir todos los idiomas modernos, admite el enhebrado de una forma u otra.

Los lenguajes más nuevos como scala y clojure están agregando soporte específico para mejorar el trabajo con múltiples hilos sin bloqueo explícito, ya que tradicionalmente ha sido la gran trampa del multihilo.

Answer 6

La respuesta corta es sí, son de un solo hilo.

La respuesta larga es que depende.

JRuby es multiproceso y se puede ejecutar en tomcat como otro código de Java. MRI (ruby predeterminado) y Python ambos tienen un GIL (Global Interpreter Lock) y por lo tanto tienen un solo hilo.

La forma en que funciona para los servidores web se complica aún más por la cantidad de configuraciones de servidores disponibles. Para la mayoría de las aplicaciones ruby ​​hay (al menos) dos niveles de servidores, un proxy/servidor de archivos estáticos como nginx y luego el servidor de la aplicación ruby.

Nginx no usa hilos como apache o tomcat, utiliza eventos no bloqueantes (y creo que procesos de trabajo bifurcados). Esto le permite tratar con niveles de concurrencia más altos que los permitidos con la sobrecarga y la ineficiencia de programación de subprocesos nativos.

Los diversos servidores de aplicaciones de ruby ​​también funcionan de diferentes maneras para obtener un alto rendimiento y concurrencia sin hilos. Thin usa libev y el modelo asincrónico como Nginx. Mongrel utiliza un grupo de procesos de trabajo por turnos. Unicorn utiliza IPC de Unix nativo (seleccione en un socket) para cargar el balance a un grupo de procesos bifurcados a través de un socket proxy maestro.

Los subprocesos son solo una forma de abordar la simultaneidad. Los procesos múltiples y los modelos destacados son un enfoque diferente que se relaciona bien con la base de Unix. Esto es fundamentalmente diferente de la forma en que Java trata al mundo.

Answer 7

CPython tiene un Global Interpreter Lock que puede reducir el rendimiento del código de subprocesos múltiples en Python. El efecto neto, en algunos casos, es que los hilos no se pueden ejecutar simultáneamente debido a la contención de bloqueo. No todas las implementaciones de Python usan un GIL, por lo que es posible que esto no se aplique a JPython, IronPython u otras implementaciones.

El lenguaje en sí admite operaciones de subprocesamiento y otras operaciones asincrónicas. Las bibliotecas de python también pueden admitir el proceso de subprocesamiento internamente sin exponerlo directamente al intérprete de Python.

Si usted ha oído nada negativo sobre Python y roscado (o que no lo soporta), es probable que alguien encontrarse con una situación en la que el GIL está causando un cuello de botella ..

Answer 8

Unos pocos Los lenguajes de programación interpretados como CPython y Ruby admiten subprocesos, pero tienen una limitación conocida como Global Intérprete de bloqueo (GIL). El GIL es un bloqueo exclusión mutua en poder del intérprete que impide que el intérprete de concurrentemente interpretar el código de aplicaciones en dos o más hilos al mismo tiempo, que limita efectivamente la concurrencia en varios sistemas centrales.

de Wikipedia Thread

Answer 9

La lectura de estas respuestas aquí ... Muchos de ellos tratan de sonar más inteligente de lo que realmente son en mi humilde opinión (im sobre todo hablando de cosas relacionadas con Rubí como esa es la que yo estoy más familiarizado con). De hecho, JRuby es actualmente la única implementación de Ruby que admite concurrencia verdadera. En JVM, los subprocesos de Ruby se asignan a subprocesos nativos del SO, sin que GIL interfiera. Así que es totalmente correcto decir que Ruby no es multiproceso. En 1.8.x, Ruby se ejecuta en realidad dentro de un subproceso del sistema operativo, y si bien tiene la sensación falsa de concurrencia con subprocesos verdes, entonces, en realidad, GIL evitará prácticamente que tenga verdadera concurrencia. En Ruby 1.9 esto cambió un poco, ya que ahora un proceso de Ruby puede tener muchos hilos del sistema operativo unidos a él (más los hilos verdes), pero de nuevo GIL destruirá totalmente el punto y se convertirá en el cuello de botella.

En la práctica, desde el punto de vista de una aplicación web normal, no debería importar mucho si es de una o varias capas. El problema surge principalmente en el lado del servidor de todos modos y en su mayoría es una cuestión de diferencia de escala de la técnica.

Answer 10

Sí Ruby and Python puede manejar multi-threading, pero para muchos casos (web) es mejor confiar en los hilos generados por las solicitudes http del cliente al servidor. Incluso si genera muchos subprocesos en una misma aplicación para reducir el costo del tiempo de ejecución o para manejar muchas tareas a la vez, en un caso de aplicación web que suele ser demasiado tiempo, nadie esperará felizmente más que algunas fracciones de segundo para la respuesta de su aplicación en una sola página, es más inteligente usar técnicas AJAX (Asynchronous JavaScript And XML): asegúrese de que el diseño de su web se muestre rápidamente y realice una inserción asíncrona de esas cosas de codificación difícil más adelante.

¡Eso no quiere decir que el multihilo sea inútil para la web! Se recomienda encarecidamente bajar la carga de tu servidor si quieres ejecutar recursive-complicated-hardcore-applications (no para un sitio web, quiero decir), pero lo que devuelve eso debe terminar en archivos o en bases de datos, entonces podría ser suavemente servido por una respuesta http.

Answer 11

Una pregunta confusa con muchas respuestas confusas ...

En primer lugar, roscado y ejecución concurrente son cosas diferentes. Python admite los hilos muy bien; no admite la ejecución concurrente en ninguna implementación en el mundo real. (En todas las implementaciones graves, solo se puede ejecutar un subproceso de VM a la vez; todos los intentos de desacoplamiento de subprocesos de VM han fallado).

En segundo lugar, esto es irrelevante para las aplicaciones web. No es necesario que los servidores de fondo de Python se ejecuten al mismo tiempo en el mismo proceso. Genera procesos separados para cada back-end, que luego pueden manejar solicitudes en paralelo porque no están vinculados entre sí.

Usar subprocesos para backends web es una mala idea. ¿Por qué introducir los peligros de enhebrar (bloqueo, condiciones de carrera, puntos muertos) a algo intrínsecamente embarazosamente paralelo? Es mucho más seguro esconder cada backend en su propio proceso aislado, evitando el potencial de todos estos problemas.

(Hay ventajas de compartir el espacio de memoria - que ahorra memoria, mediante el intercambio de código estático -, sino que se pueden resolver sin hilos.)