Смущены, языки как питон, рубин однопотоковый? в отличие от, скажем, Java? (для веб-приложений)

Question

Я читал, как Clojure «крут» из-за его синтаксиса + он работает на JVM, поэтому он многопоточный и т. Д. И т. Д.

Являются ли такие языки, как ruby ​​и python, однопоточными по своей природе?(при работе в качестве веб-приложения).

Каковы основные различия между python / ruby ​​и, скажем, java, работающими на tomcat?

Разве на веб-сервере нет пула потоков для работыво всех случаях?

Answer 1

И Python, и Ruby имеют полную поддержку многопоточности.Существует несколько реализаций (например, CPython, MRI, YARV), которые на самом деле не могут запускать потоки параллельно, но это ограничение этих конкретных реализаций, а не языка.Это похоже на Java, где также есть некоторые реализации, которые не могут запускать потоки параллельно, но это не означает, что Java является однопоточным.

Обратите внимание, что в обоих случаях существует множество реализаций, которые может запускать потоки параллельно: PyPy, IronPython, Jython, IronRuby и JRuby - это лишь несколько примеров.

Основное различие между Clojure с одной стороны и Python, Ruby, Java, C #С другой стороны, C ++, C, PHP и почти любой другой основной и не очень распространенный язык - это то, что Clojure имеет модель параллелизма sane .Все остальные языки используют потоки, которые, как мы знаем, являются плохой моделью параллелизма в течение как минимум 40 лет.Clojure OTOH имеет разумную модель обновления, которая позволяет программисту представлять не только одну, но фактически несколько моделей разумного параллелизма: атомарные обновления, программную транзакционную память, асинхронные агенты, глобальные переменные локальных потоков с учетом параллелизма, фьючерсы, обещания, параллелизм потока данныхи в будущем, возможно, даже больше.

Answer 2

запутанный вопрос с большим количеством запутанных ответов ...

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Длинный ответ - это зависит.

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

Python

Позвольте мне попытаться выразить это проще, чем более подробные ответы.

Суть ответа здесь на самом деле не связана с тем, что Python является однопоточным, а не многопоточным. Это больше связано с многопоточностью, чем многопоточностью.

То, что Python является «однопоточным», на самом деле не отражает реальность, потому что вы, безусловно, можете запустить несколько процессов в процессе Python. Просто используйте библиотеку потоков и создайте несколько потоков. Теперь вы только что доказали, что Python не является однопоточным.

Но использование нескольких потоков в Python НЕ означает, что вы используете несколько процессоров одновременно. Фактически, Глобальная Блокировка Интерпретатора предотвращает это. Так вот где возникают вопросы.

По сути, многопоточность в Python не может использоваться для параллельных вычислений ЦП. Но вы МОЖЕТЕ выполнять параллельные вычисления ЦП с Python, используя многопроцессорность вместо многопоточность .

Я нашел эту статью очень полезной при исследовании этого: https://timber.io/blog/multiprocessing-vs-multithreading-in-python-what-you-need-to-know/. Он включает в себя примеры из реальной жизни, когда вы хотите использовать многопроцессорность против многопоточности.

Answer 9

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

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

Answer 10

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

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