Перепутанный, похожи на Python языков, рубиновый сингл распараллелил? в отличие от этого, говорят Java? (для веб-приложений)

Несколько интерпретируемых программ такие языки, как CPython и Ruby поддержка потоковой передачи, но есть ограничение, известное как глобальное Блокировка переводчика (GIL). GIL - это блокировка взаимного исключения, удерживаемая переводчик, который предотвращает переводчик из одновременно интерпретация кода приложения на два или более потока одновременно, что эффективно ограничивает параллелизм в многоядерных системах.

из википедии Тема

Запутанный вопрос с множеством запутанных ответов ...

Во-первых, многопоточность и параллельное выполнение - разные вещи. Python отлично поддерживает потоки; он не поддерживает параллельное выполнение ни в одной реальной реализации. (Во всех серьезных реализациях одновременно может выполняться только один поток виртуальной машины; все многочисленные попытки разъединить потоки виртуальной машины потерпели неудачу.)

Во-вторых, это не имеет отношения к веб-приложениям. Вам не нужны бэкенды Python для одновременного выполнения в одном процессе . Вы создаете отдельных процессов для каждого бэкэнда, которые затем могут обрабатывать запросы параллельно, потому что они вообще не связаны друг с другом.

Использование потоков для веб-серверов - плохая идея. Зачем вводить опасности многопоточности - блокировки, состояния гонок, взаимоблокировки - с чем-то изначально смущающе параллельным? Гораздо безопаснее разместить каждый серверный модуль в отдельном изолированном процессе, чтобы избежать всех этих проблем.

(Есть преимущества совместного использования пространства памяти - это экономит память за счет совместного использования статического кода, но это может быть решено без потоков.)

CPython имеет глобальную блокировку интерпретатора, которая может снизить производительность многопоточного кода в Python. В некоторых случаях чистый эффект заключается в том, что потоки не могут работать одновременно из-за борьбы за блокировку. Не все реализации Python используют GIL, поэтому это может не относиться к JPython, IronPython или другим реализациям.

Сам язык поддерживает потоки и другие асинхронные операции. Библиотеки python также могут поддерживать многопоточность внутри языка, не передавая ее напрямую интерпретатору Python.

Если вы слышали что-то негативное о Python и потоковых операциях (или о том, что он их не поддерживает), то, вероятно, кто-то столкнулся с ситуацией, когда GIL создает узкое место.

Безусловно, веб-сервер будет иметь пул потоков. Это только вне контроля вашей программы. Эти потоки используются для обработки HTTP-запросов. Каждый HTTP-запрос обрабатывается в отдельном потоке, и поток возвращается обратно в пул, когда соответствующий HTTP-ответ завершен. Если бы у веб-сервера не было такого пула, он бы обслуживался крайне медленно.

Является ли язык программирования однопоточным или многопоточным, зависит от возможности программного порождения новых потоков с помощью данного языка. Если это невозможно, то язык является однопоточным, например PHP. Насколько я могу судить, и Ruby, и Python поддерживают многопоточность.

Короткий ответ - да, они однопоточные.

Длинный ответ: это зависит от обстоятельств.

JRuby является многопоточным и может запускаться в Tomcat, как и другой Java-код. MRI (ruby по умолчанию) и Python имеют GIL (Global Interpreter Lock) и, таким образом, являются однопоточными.

То, как это работает для веб-серверов, еще больше усложняется из-за количества доступных конфигураций серверов. Для большинства приложений Ruby существует (как минимум) два уровня серверов: прокси-сервер / статический файловый сервер, такой как nginx, а затем сервер приложений ruby.

Nginx не использует потоки, такие как apache или tomcat, он использует неблокирующие события (и, как мне кажется, разветвленные рабочие процессы). Это позволяет ему работать с более высокими уровнями параллелизма, чем это было бы допустимо из-за накладных расходов и неэффективности планирования собственных потоков.

Различные серверы приложений Ruby также работают по-разному, чтобы обеспечить высокую пропускную способность и параллелизм без потоков. Thin использует libev и асинхронную событийную модель, такую ​​как Nginx. Mongrel использует круговой пул рабочих процессов. Unicorn использует собственный IPC Unix (выбор на сокете) для балансировки нагрузки в пул разветвленных процессов через один главный прокси-сокет.

Потоки - это только один способ решить проблему параллелизма. Множественные процессы и четные модели - это другой подход, который хорошо согласуется с базой Unix. Это фундаментально отличается от того, как Java относится к миру.

Большинство языков не определяют однопоточность или многопоточность. Обычно это остается на усмотрение библиотек.

При этом некоторые языки справляются с этим лучше, чем другие. Например, CPython имеет проблемы с блокировкой интерпретатора во время многопоточности, а Jython (python, работающий на JVM) - нет.

Одной из реальных возможностей Clojure (IMO) является то, что он работает на JVM. Вы получаете многопоточность и множество библиотек бесплатно.

Читая эти ответы здесь ... Многие из них пытаются казаться умнее, чем они есть на самом деле, imho (я в основном говорю о вещах, связанных с Ruby, так как это то, что я наиболее знаком с). Фактически, JRuby в настоящее время является единственной реализацией Ruby, которая поддерживает настоящий параллелизм. В JVM потоки Ruby отображаются на собственные потоки ОС без вмешательства GIL. Поэтому совершенно правильно сказать, что Ruby не является многопоточным. В 1.8.x Ruby на самом деле выполняется внутри одного потока ОС, и хотя у вас есть ложное ощущение параллелизма с зелеными потоками, на самом деле GIL в значительной степени помешает вам получить настоящий параллелизм. В Ruby 1.9 это немного изменилось, так как теперь к процессу Ruby может быть прикреплено много потоков ОС (плюс зеленые потоки), но снова GIL полностью разрушит суть и станет узким местом.

На практике, с точки зрения обычного веб-приложения, не имеет большого значения, однопоточный он или многопоточный. Проблема в основном возникает на стороне сервера, и это в основном вопрос разницы в технике масштабирования.

Ruby

Интерпретатор Ruby является однопоточным, что означает, что некоторые из его методов не являются потокобезопасными.

В мире Rails этот однопоточный поток в основном передается на сервер. Итак, вы увидите, что nginx работает с пулом беспородных серверов, каждый из которых имеет интерпретатор в памяти, обрабатывает 1 запрос за раз и в своем собственном потоке.

Passenger, запускающий "ruby enterprise" , привносит в Rails концепцию сборки мусора и некоторую безопасность потоков, и это приятно.

В Rails еще предстоит проделать работу в этой области, но она продвигается медленно - но в целом идея состоит в том, чтобы иметь несколько сервисов и серверов.

Как распутать узлы во всех этих потоках ...

Clojure не изобретал потоки, однако он особенно сильно поддерживает его с помощью программной транзакционной памяти, атомов, агентов , параллельные операции сопоставления, ...

Все остальные имеют накопленную поддержку потоковой передачи. Ruby - это особый случай, поскольку в некоторых реализациях он имеет зеленые потоки, которые являются своего рода программно эмулируемыми потоками и не используют все ядра. 1.9 положит конец этому.

Что касается веб-серверов, нет, они не всегда работают в многопоточном режиме, apache традиционно работает как группа демонов, которые представляют собой пул отдельных однопоточных процессов. Теперь в настоящее время есть больше возможностей для запуска серверов apache.

Подводя итог, все современные языки поддерживают многопоточность в той или иной форме.

Новые языки, такие как scala и clojure, добавляют специальную поддержку для улучшения работы с несколькими потоками без явной блокировки, поскольку это традиционно было большой ловушкой многопоточности.

Да, Ruby и Python могут работать с многопоточностью, но для многих случаев (веб) лучше полагаться на потоки, генерируемые http-запросами от клиента к серверу. Даже если вы генерируете много потоков в одном приложении, чтобы снизить стоимость выполнения или обрабатывать много задач одновременно, в случае веб-приложения это обычно слишком много времени, никто не будет счастливо ждать ответа вашего приложения на одной странице более нескольких долей секунды, разумнее использовать технику AJAX (Asynchronous JavaScript And XML): убедитесь, что дизайн вашего сайта быстро отображается, и сделайте асинхронную вставку этих жестко закодированных вещей позже.

Это не означает, что многопоточность бесполезна для веб! Настоятельно рекомендуется снизить нагрузку на сервер, если вы хотите запускать рекурсивные-сложные-хардкорные-приложения (не для сайта, я имею в виду), но то, что эта штука возвращает, должно заканчиваться в файлах или в базах данных, чтобы потом можно было мягко обслужить http-ответ.