Я читал, как Clojure является "классным" из-за его синтаксиса + он работает на JVM, поэтому он многопоточен и т.д. и т.д.
Существуют ли такие языки, как ruby и python, в одном потоке? (при работе в качестве веб-приложения).
В чем основные отличия между python/ruby и java работает на tomcat?
Во всех случаях веб-сервер не имеет пула потоков?
Оба Python и Ruby имеют полную поддержку многопоточности. Существуют некоторые реализации (например, CPython, MRI, YARV), которые не могут фактически запускать потоки параллельно, но это ограничение этих конкретных реализаций, а не языка. Это похоже на Java, где также есть некоторые реализации, которые не могут запускать потоки параллельно, но это не значит, что Java является однопоточным.
Обратите внимание, что в обоих случаях существует множество реализаций, которые могут запускать потоки параллельно: PyPy, IronPython, Jython, IronRuby и JRuby - всего лишь несколько примеров.
Основное различие между Clojure с одной стороны и с Python, Ruby, Java, С#, С++, C, PHP и почти всем другим основным и не очень распространенным языком с другой стороны заключается в том, что Clojure имеет разумную модель concurrency. Все остальные языки используют потоки, которые, как мы знаем, являются плохой моделью concurrency не менее 40 лет. Clojure OTOH имеет разумную модель обновления, которая позволяет ему не только представить один, но фактически многозначные модели concurrency программисту: атомные обновления, транзакционная память программного обеспечения, асинхронные агенты, concurrency - определить глобальные переменные потока, фьючерсы, promises, поток данных concurrency и в будущем возможно даже больше.
Смущенный вопрос с множеством путаных ответов...
Во-первых, потоковое и параллельное выполнение - это разные вещи. Python поддерживает потоки просто отлично; он не поддерживает одновременное выполнение в любой реальной реализации. (Во всех серьезных реализациях может выполняться только один поток VM, многие попытки развязать потоки VM все провалились.)
Во-вторых, это не относится к веб-приложениям. Вам не нужны Python-серверы для одновременного выполнения в одном процессе. Вы создаете отдельные процессы для каждого бэкэнд, которые могут обрабатывать каждый запрос параллельно, потому что они не связаны вообще.
Использование потоков для веб-бэкэндов - плохая идея. Зачем вводить опасности запирания резьбы - запирание, условия гонки, тупики - к чему-то по своей сути смущающей параллели? Гораздо безопаснее сбрасывать каждый бэкэнд в своем изолированном процессе, избегая возможности для всех этих проблем.
(Есть преимущества для совместного использования памяти - это экономит память, разделяя статический код - но это можно решить без потоков.)
CPython имеет Global Interpreter Lock, который может снизить производительность многопоточного кода в Python. В некоторых случаях чистый эффект заключается в том, что потоки не могут выполняться одновременно из-за конкуренции за блокировку. Не все реализации Python используют GIL, поэтому это может не относиться к JPython, IronPython или другим реализациям.
Сам язык поддерживает многопоточность и другие асинхронные операции. Библиотеки python также могут поддерживать потоки внутри, не подвергая их непосредственно интерпретатору Python.
Если вы слышали что-то отрицательное о Python и потоке (или что оно не поддерживает его), вероятно, кто-то сталкивается с ситуацией, когда GIL вызывает узкое место.
Большинство языков не определяют одно или многопоточность. Обычно это сохраняется до библиотек для реализации.
При этом некоторые языки лучше, чем другие. CPython, например, имеет проблемы с блокировкой интерпретатора во время многопоточности, Jython (python, запущенный на JVM) не делает.
Некоторая реальная мощность Clojure (IMO) заключается в том, что она работает на JVM. Вы получаете многопоточность и тонны библиотек бесплатно.
Короткий ответ: да, они однопоточные.
Долгий ответ - это зависит.
JRuby многопоточен и может быть запущен в tomcat, как и другой Java-код. MRI (по умолчанию ruby) и Python имеют GIL (Global Interpreter Lock) и, таким образом, однопоточные.
То, как он работает для веб-серверов, еще больше осложняется количеством доступных конфигураций сервера. Для большинства рубиновых приложений есть (по крайней мере) два уровня серверов, прокси-сервер/статический файловый сервер, например nginx, а затем сервер приложений ruby.
Nginx не использует потоки, такие как apache или tomcat, использует неблокирующие события (и я думаю, что разветвленные рабочие процессы). Это позволяет ему иметь дело с более высокими уровнями concurrency, чем это допускается с помощью служебных и графических неэффективности собственных потоков.
Различные серверы рубиновых приложений также работают по-разному, чтобы получить высокую пропускную способность и concurrency без потоков. Тонкий использует libev и асинхронную модель, подобную Nginx. Mongrel использует круглый пул рабочих процессов. Unicorn использует собственный Unix IPC (выберите в сокете), чтобы загрузить баланс в пул разветвленных процессов через один мастер-прокси-сокет.
Потоки - это только один способ обращения к concurrency. Несколько процессов и событийных моделей - это другой подход, который хорошо связан с базой Unix. Это принципиально отличается от того, как Java относится к миру.
Конечно, у веб-сервера будет пул потоков. Это только вне контроля вашей программы. Эти потоки используются для обработки HTTP-запросов. Каждый HTTP-запрос обрабатывается в отдельном потоке, и поток возвращается в пул, когда связанный HTTP-ответ завершен. Если у веб-сервера нет такого пула, он был бы очень медленным в обслуживании.
Является ли язык программирования однопоточным или многопоточным, зависит от возможности программно создавать потоки new, используя соответствующий язык. Если это невозможно, то язык является односторонним, например PHP. Насколько я понимаю, оба Ruby и Python поддерживают многопоточность.
Несколько интерпретируемых программ языки, такие как CPython и Ruby поддерживать резьбу, но ограничение, известное как глобальное Блокировка переводчика (GIL). GIL - это блокировка взаимного исключения, удерживаемая интерпретатор, который предотвращает переводчика одновременно интерпретация кода приложения на два или более потоков одновременно, который эффективно ограничивает concurrency в многоядерных системах.
из wikipedia Thread
рубин
Интерпретатор Ruby является однопоточным, то есть несколько его методов не являются потокобезопасными.
В мире Rails этот однопоточный поток в основном переносится на сервер. Итак, вы увидите, что nginx работает с пулом mongrel-серверов, каждый из которых имеет интерпретатор в памяти, обрабатывает 1 запрос за раз и в своем собственном потоке.
Пассажир, работающий ruby enterprise привносит концепцию сбора мусора и некоторую поточную безопасность в Rails, и это приятно.
В Rails все еще предстоит работать, но это происходит медленно, но в целом идея состоит в том, чтобы иметь несколько сервисов и серверов.
Как распутать узлы во всех этих потоках...
Clojure не придумывал потоки, однако он особенно поддерживал его с помощью программной транзакционной памяти, атомов, агентов, операций параллельной карты,...
Все остальные накопили поддержку потоковой передачи. Ruby - это особый случай, поскольку он имеет зеленые потоки в некоторых реализациях, которые являются своего рода программным эмулированным потоком и не используют все ядра. 1.9 остановит это.
Что касается веб-серверов, они не всегда работают многопоточно, апач традиционно работает как стая демонов, которые представляют собой пул отдельных однопоточных процессов. В настоящее время существует больше возможностей для запуска Apache-серверов.
Подводя итог всем современным языкам, поддерживаем потоки в той или иной форме.
Новые языки, такие как scala и clojure, добавляют определенную поддержку для улучшения работы с несколькими потоками без явной блокировки, поскольку это традиционно является большой ошибкой многопоточности.
Чтение этих ответов здесь... Многие из них стараются казаться умнее, чем они действительно являются imho (в основном они говорят о материалах, связанных с Ruby, как тот, с которым я больше всего знаком). Фактически, JRuby в настоящее время является единственной реализацией Ruby, которая поддерживает true concurrency. В потоках JVM Ruby отображаются в собственные потоки ОС, без вмешательства GIL. Поэтому совершенно правильно сказать, что Ruby не многопоточен. В 1.8.x Ruby фактически запускается внутри одного потока ОС, и, хотя у вас есть фальшивое чувство concurrency с зелеными потоками, тогда на самом деле GIL в значительной степени помешает вам иметь истинный concurrency. В Ruby 1.9 это немного изменилось, так как теперь к процессу Ruby может подключаться много потоков ОС (плюс зеленые потоки), но снова GIL полностью уничтожит точку и станет узким местом.
На практике, с обычной точки зрения webapp, это не имеет большого значения, если ее однопользовательская или многопоточная. Проблема в основном возникает на стороне сервера, и в основном это вопрос разницы в технологиях масштабирования.
Да Ruby и Python могут обрабатывать многопоточность, но для многих случаев (web) лучше полагаться на потоки, созданные HTTP-запросами от клиента на сервер. Даже если вы создаете много потоков в одном приложении, чтобы снизить затраты времени исполнения или обрабатывать многие задачи вовремя, в случае веб-приложения, которое обычно слишком много времени, никто не будет ждать счастливо больше, чем некоторые доли секунды для ответа ваше приложение на одной странице, более разумно использовать методы AJAX (асинхронный JavaScript и XML): убедитесь, что дизайн вашего веб-сайта быстро растет, и сделайте асинхронную вставку этих файлов жесткого кодирования позже.
Это не означает, что многопоточность бесполезна для Интернета! Настоятельно рекомендуется снизить стоимость вашего сервера, если вы хотите запускать рекурсивно-сложные хардкорные приложения (а не для веб-сайта, я имею в виду), но то, что эта вещь возвращается, должна заканчиваться в файлах или в базах данных, поэтому может быть мягко обслуживается ответом на http.