ventajas - Confundido, ¿son lenguajes como python, ruby single threaded? a diferencia de decir java?(para aplicaciones web)
similitud de java y python (11)
Algunos lenguajes de programación interpretados como CPython y Ruby admiten subprocesos, pero tienen una limitación que se conoce como bloqueo global de intérpretes (GIL). El GIL es un bloqueo de exclusión mutua mantenido por el intérprete que evita que el intérprete interprete simultáneamente el código de las aplicaciones en dos o más subprocesos al mismo tiempo, lo que limita efectivamente la concurrencia en varios sistemas centrales.
de wikipedia Thread
Estaba leyendo cómo Clojure es "genial" debido a su sintaxis + se ejecuta en la JVM, por lo que es multiproceso, etc.
¿Los lenguajes como ruby y python son solo hilos en la naturaleza? (cuando se ejecuta como una aplicación web).
¿Cuáles son las diferencias subyacentes entre python / ruby y say java ejecutándose en tomcat?
¿No tiene el servidor web un conjunto de hilos para trabajar en todos los casos?
Cómo desenredar los nudos en todos esos hilos ...
Clojure no inventó el subprocesamiento, sin embargo, tiene un soporte particularmente fuerte para él con memoria transaccional de software, átomos, agentes, operaciones de mapas paralelos, ...
Todos los demás tienen soporte de roscado acumulado. Ruby es un caso especial ya que tiene subprocesos verdes en algunas implementaciones que son un tipo de subprocesos emulados de software y no utilizan todos los núcleos. 1.9 pondrá esto a descansar.
Con respecto a los servidores web, no siempre funcionan multihebra, tradicionalmente, apache se ha ejecutado como una bandada de demonios que son un conjunto de procesos de un solo hilo separados. Ahora hay actualmente más opciones para ejecutar servidores apache.
Para resumir, todos los lenguajes modernos admiten subprocesos 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 subprocesos sin un bloqueo explícito, ya que tradicionalmente ha sido el gran escollo de los subprocesos múltiples.
CPython tiene un bloqueo global de intérprete que puede reducir el rendimiento del código de subprocesos múltiples en Python. El efecto neto, en algunos casos, es que los subprocesos no pueden ejecutarse simultáneamente debido a la contención de bloqueo. No todas las implementaciones de Python utilizan una GIL, por lo que es posible que esto no se aplique a JPython, IronPython u otras implementaciones.
El lenguaje en sí es compatible con subprocesos y otras operaciones asíncronas. Las bibliotecas de Python también pueden admitir subprocesos internamente sin exponerlos directamente al intérprete de Python.
Si ha escuchado algo negativo acerca de Python y de los hilos (o que no lo admite), es probable que alguien se encuentre en una situación en la que el GIL está causando un cuello de botella.
Ciertamente, el servidor web tendrá un conjunto de subprocesos. Eso es solo fuera del control de su programa. Esos hilos se utilizan para manejar solicitudes HTTP. Cada solicitud HTTP se maneja en un subproceso separado y el subproceso se libera de nuevo al grupo cuando finaliza la respuesta HTTP asociada. Si el servidor web no tiene tal grupo, habría sido extremadamente lento en el servicio.
El hecho de que un lenguaje de programación sea de un solo hilo o de múltiples hilos depende de la posibilidad de generar nuevos hilos mediante el uso del lenguaje en cuestión. Si eso no es posible, entonces el lenguaje es único, por ejemplo, PHP. Por lo que puedo ver, tanto Ruby como Python admiten subprocesos múltiples.
La mayoría de los idiomas no definen solo o multihilo. Por lo general, eso se deja a las bibliotecas para implementar.
Dicho esto, algunos idiomas son mejores que otros. CPython, por ejemplo, tiene problemas con el bloqueo del intérprete durante el subprocesamiento múltiple, Jython (python que se ejecuta en la JVM) no.
Parte del poder real de Clojure (IMO) es que se ejecuta en la JVM. Usted obtiene multihilo y toneladas de bibliotecas de forma gratuita.
La respuesta corta es sí, son solo hilos.
La respuesta larga es que depende.
JRuby es multiproceso y puede ejecutarse en Tomcat como cualquier otro código Java. MRI (ruby predeterminado) y Python tienen ambos 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 el número de configuraciones de servidor disponibles. Para la mayoría de las aplicaciones ruby, hay (al menos) dos niveles de servidores, un servidor de archivos proxy / estático como nginx y luego el servidor de aplicaciones ruby.
Nginx no usa subprocesos como apache o tomcat, usa eventos sin bloqueo (y creo que los procesos de trabajo bifurcados). Esto le permite lidiar con niveles más altos de concurrencia de lo que se permitiría con la sobrecarga y la programación de ineficiencias de los subprocesos nativos.
Los diversos servidores de aplicaciones ruby también funcionan de diferentes maneras para obtener un alto rendimiento y concurrencia sin subprocesos. Thin usa libev y el modelo de eventos asíncronos como Nginx. Mongrel utiliza un grupo de procesos de trabajadores de turno redondo. Unicorn utiliza IPC de Unix nativo (selección en un socket) para cargar el equilibrio en un grupo de procesos bifurcados a través de un socket proxy maestro.
Los hilos son solo una forma de abordar la concurrencia. Los procesos múltiples y los modelos de eventos 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.
Leyendo estas respuestas aquí ... Muchos de ellos intentan sonar más inteligentes de lo que realmente son imho (en su mayoría estoy hablando de cosas relacionadas con Ruby, ya que es con la que estoy más familiarizado). De hecho, JRuby es actualmente la única implementación de Ruby que admite la verdadera concurrencia. En JVM, los subprocesos de Ruby se asignan a subprocesos nativos del sistema operativo, sin interferencia de GIL. Así que es totalmente correcto decir que Ruby no es multiproceso. En la versión 1.8.x, Ruby se ejecuta dentro de un subproceso del sistema operativo, y si bien tiene la falsa sensación de concurrencia con los subprocesos verdes, en realidad GIL evitará que tenga la verdadera concurrencia. En Ruby 1.9 esto cambió un poco, ya que ahora un proceso de Ruby puede tener muchos subprocesos del sistema operativo conectados (más los subprocesos 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 único o multihilo. El problema surge principalmente en el lado del servidor de todos modos y en su mayor parte es una cuestión de diferenciación técnica.
Sí, Ruby y Python pueden manejar subprocesos múltiples, pero para muchos casos (web) es mejor confiar en los subprocesos generados por las solicitudes http desde el cliente al servidor. Incluso si genera muchos subprocesos en una misma aplicación para reducir el costo de 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 por la respuesta de su aplicación en una sola página, es más sabio usar técnicas AJAX (JavaScript asíncrono y 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 rígida más adelante.
¡Eso no significa que los subprocesos múltiples sean inútiles para la web! Es altamente recomendable reducir la carga de su servidor si desea ejecutar aplicaciones recursivas-complicadas-incondicionales (no para un sitio web, quiero decir), pero lo que devuelva debe terminar en archivos o en bases de datos, por lo que podría ser suave servido por una respuesta http.
Tanto Python como Ruby tienen soporte completo para subprocesos múltiples. 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 sea de un solo subproceso.
Tenga en cuenta que en ambos casos hay muchas implementaciones que pueden ejecutar subprocesos en paralelo: PyPy, IronPython, Jython, IronRuby y JRuby son solo algunos de los ejemplos.
La principal diferencia entre Clojure en un lado y Python, Ruby, Java, C #, C ++, C, PHP y casi todos los otros lenguajes principales y no tan comunes en el otro lado es que Clojure tiene un modelo de concurrencia sensato . Todos los demás lenguajes utilizan subprocesos, que hemos conocido como un mal modelo de concurrencia durante al menos 40 años. Clojure OTOH tiene un modelo de actualización sensato que le permite no solo presentar uno sino también múltiples modelos de concurrencia sanos al programador: actualizaciones atómicas, memoria transaccional de software, agentes asíncronos, variables globales de subprocesos que reconocen la concurrencia, futuros, promesas, concurrencia de flujo de datos y en el futuro posiblemente aún más.
Una pregunta confusa con muchas respuestas confusas ...
Primero, los hilos y la ejecución concurrente son cosas diferentes. Python soporta hilos muy bien; no admite la ejecución concurrente en ninguna implementación del mundo real. (En todas las implementaciones serias, solo se puede ejecutar un subproceso de VM a la vez; todos los intentos de desacoplar los subprocesos de VM han fallado).
En segundo lugar, esto es irrelevante para las aplicaciones web. No es necesario que los backends de Python se ejecuten simultáneamente en el mismo proceso . Genera procesos separados para cada backend, que pueden manejar solicitudes en paralelo porque no están vinculados en absoluto.
El uso de hilos para backends web es una mala idea. ¿Por qué introducir los peligros de subprocesos (bloqueo, condiciones de carrera, interbloqueos) a algo inherentemente embarazoso paralelo? Es mucho más seguro guardar cada backend en su propio proceso aislado, evitando el potencial de todos estos problemas.
(Hay ventajas en compartir espacio en la memoria, ya que ahorra memoria al compartir código estático, pero eso se puede resolver sin subprocesos).
Rubí
El intérprete de Ruby es un solo hilo, lo que quiere decir que varios de sus métodos no son seguros para subprocesos.
En el mundo de Rails, este hilo único ha sido principalmente enviado al servidor. Por lo tanto, verá que nginx se ejecuta 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, ejecutando "ruby enterprise" trae el concepto de recolección de basura y algo de seguridad de hilos a Rails, y es agradable.
Aún queda trabajo por hacer en Rails en esta área, pero está llegando lentamente, pero en general, la idea es tener múltiples servicios y servidores.