Авторы на сайте в FAQ объяснили зачем python нужен. В основном, как я понял, для ускорения выполнения простых обслуживающих задач типа создания нового приложения, запуска веб-сервера и т.п. Запуск JVM очевидно медленнее, чем запуск интерпретатора питона.
А Вы не могли бы поконкретнее? А то я, может быть, и рад бы разобраться в том, в чем я с Вашей точки зрения не разбираюсь. Но из Вашего коммента совершенно не ясно.
А после Ваших торгово-строительных аналогий, я бы вообще поосторожней чужие примеры (особенно вполне удачные, как в данном случае) называл нелогичными :)
А Вы уже, наверное, все, что у Вас было выкурили :)
Kernel#select и потоки — это альтернативные способы решения приведенной задачи (организации веб-сервера, да и сервера любого другого типа вообще). И Вы еще попробуйте с использованием голого select (без фреймворка типа EventMachine) реализовать более-менее сложный сервер. Чтобы он как минимум был также эффективен, как аналогичный сервер, реализованный через потоки, который и реализовать, и поддерживать куда проще.
Т.е. тот факт, что на одном ядре одновременно может выполняться только один поток, по-вашему является достаточным основанием для отказа от многопоточного программирования в Ruby? Объясните мне тогда, что в других языках это как по-другому? Может от него вообще в принципе стоит отказаться?
И интересно, что выражение «гарантированно получит» значит. Вы его как-то особенно выделили. Т.е. другие треды получат меньше процессорного времени, чем им нужно или они просто не выполнятся. Что с ними по-вашему произойдет?
Слушайте, это все здорово, но я же Вас не о том спрашиваю. Я хорошо представляю, как устроена поточная модель и в 1.8, и в 1.9.1. Т.ч. перестаньте, пожалуйста, сыпать ссылками и цитатами.
Меня интересует простая вещь (наверное, простая) относительно Вашего первого комментария. Что это за правило такое: количество потоков = количество ядер.
Просто Вам вот там плюсы ставят за этот комментарий. А я, честно говоря, не понимаю за что. Вы мне объясните.
Во-первых, информация в цитате, которую Вы приводите, устарела. Текущий стабильный релиз (1.9.1) уже не использует userspace threads. Используются нативные потоки. Хотя все равно присутсвует GIL.
Во-вторых, возвращаясь к моему вопросу. О каком распараллеливании Вы говорите, если Вы утверждаете, что потоки надо использовать по количеству ядер? Т.е. на одноядерной машине, не более одного потока.
Интересные заявления Вы делаете. Вы предлагаете забить на многопоточность, если в системе одно ядро? Откуда Вы это правило взяли: количество ядер = количество потоков?
Clutch уже достаточно давно влился в основную ветку transmission и теперь называется Transmission Web Client.
Я только к тому, что, если кто-то решит воспользоваться мануалом, то лучше им все-таки не пользоваться. Он уже порядком устарел вместе с версиями, которые там описываются.
Для тех, кто не гнушается пользоваться тестовым репозитарием, самый беспроблемный способ — ставить из него. Я не гнушаюсь (на домашней машине) — работает на ура. Из пакетов можно поставить и веб-интерфейс, и демона. Останется только настроить конфиг.
Ну, или можно собрать свежий transmission самостоятельно. Автор статьи об этом уже писал.
Kernel#select и потоки — это альтернативные способы решения приведенной задачи (организации веб-сервера, да и сервера любого другого типа вообще). И Вы еще попробуйте с использованием голого select (без фреймворка типа EventMachine) реализовать более-менее сложный сервер. Чтобы он как минимум был также эффективен, как аналогичный сервер, реализованный через потоки, который и реализовать, и поддерживать куда проще.
И интересно, что выражение «гарантированно получит» значит. Вы его как-то особенно выделили. Т.е. другие треды получат меньше процессорного времени, чем им нужно или они просто не выполнятся. Что с ними по-вашему произойдет?
Меня интересует простая вещь (наверное, простая) относительно Вашего первого комментария. Что это за правило такое: количество потоков = количество ядер.
Просто Вам вот там плюсы ставят за этот комментарий. А я, честно говоря, не понимаю за что. Вы мне объясните.
Во-вторых, возвращаясь к моему вопросу. О каком распараллеливании Вы говорите, если Вы утверждаете, что потоки надо использовать по количеству ядер? Т.е. на одноядерной машине, не более одного потока.
Я только к тому, что, если кто-то решит воспользоваться мануалом, то лучше им все-таки не пользоваться. Он уже порядком устарел вместе с версиями, которые там описываются.
Для тех, кто не гнушается пользоваться тестовым репозитарием, самый беспроблемный способ — ставить из него. Я не гнушаюсь (на домашней машине) — работает на ура. Из пакетов можно поставить и веб-интерфейс, и демона. Останется только настроить конфиг.
Ну, или можно собрать свежий transmission самостоятельно. Автор статьи об этом уже писал.