LINUX.ORG.RU

[lorgoogle] Green Threads vs Coroutines

 


0

1

Green threads я имею ввиду те, что в ерланге.

Предположим есть задача: приложение в процессе обработки запроса делает удаленный вызов, например к базе данных. Как я понимаю, в ерланге мы запустим процесс «запросить из БД», который при получении данных отправит их родительскому сообщению. Умная VM все распараллелит, используя гибридные треды. Есть другое решение - использовать корутины питона (по сути кооперативная многозадачность или я ошибаюсь?) и неблокирующий ввод-вывод. Кто кого в этом случае?

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

Вобщем хочется пофилосовствовать на тему оптимальной стратегии ассинхронной обработки IO-операций.

★★★★★

> Вобщем хочется пофилосовствовать на тему оптимальной стратегии

ассинхронной обработки IO-операций


Не надо философствовать, просто бери Node.js и пользуйся.

archimag ★★★
()

Кто кого в этом случае?

что лучше знаешь на том и пиши. Я использую python+gevent. В принципе, нравится, хотя внутрях он местами не совсем понятный.

true_admin ★★★★★
()
Ответ на: комментарий от archimag

> бери Node.js и пользуйся.

хохо, очень интересно. есть какие-то истории успеха? а то у нас тут граждане хотят на нем запилить сервант для web-а, а я чет даже не знаю «за» я, или «против»...

Rastafarra ★★★★
()

Еще я так понимаю неблокирующий ввод-ввывод можно и в ерланге замутить.

Он там и так неблокирующий внутри (обычный AMP между нашим лёгким процессом и процессом выполняющим IO).

Вот ещё на эту же тему было:

http://www.linux.org.ru/jump-message.jsp?msgid=5711126&cid=5711701

http://www.linux.org.ru/jump-message.jsp?msgid=5693646&cid=5694949

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

Но на тему пи-исчисления Милнера - Армстронг в интервью говорил, что они сначала просто взяли пролог и прикрутили к нему лёгкие процессы и обмен сообщениями, и ни о каком пи-исчислении не думали - это потом оказалось что оно подходит для описания подобных систем.

quasimoto ★★★★
()
Ответ на: комментарий от true_admin

На сколько я понял разница в том, что green threads - это вытесняющая многозадачность, а coroutines - кооперативная.

dizza ★★★★★
() автор топика
Ответ на: комментарий от dizza

нет, у green threads тоже кооперативная. Я думаю это одно и тоже.

true_admin ★★★★★
()

В эрланге просто нету блокирующего ввода-вывода. Поправьте если не так.

На питоне можешь через twisted/gevent (ну или еще что там есть у вас). Я на Ruby через EventMachine всё к примеру делаю.

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

tensai_cirno ★★★★★
()
Ответ на: комментарий от true_admin

По-моему, coroutines и green threads это одно и тоже, не? :)

Не, это всё разные вещи.

Green threads это вообще любая реализация многозадачности средствами VM - это может быть планировщик с обычным квантом времени (как в старом CMU CL, например), или что-то другое, лишь бы не треды хост ОСи.

Сoroutines это вовсе не реализация многозадачности, а просто небольшое дополнение рантайма (до возможности использовать функции с yield, т.е. как сопрограммы).

Ну и то что в ерланге (в jocaml и в куске GHC) это «легковесные процессы» — зелёные нити на основе (условно) автоматических сопрограм, т.е. планирование задач производится на основе редукций (можно считать это автоматическим вызовом yield и проявлением вытесняющей многозадачности внутри VM).

quasimoto ★★★★
()
Ответ на: комментарий от tensai_cirno

>А вообще можно просто взять node.js ☺

По сути, вручную писать в CPS-стиле, без нормальный поддержки конструкций типа try...catch? Да вы эстет...

WFrag ★★★★
()
Ответ на: комментарий от WFrag

Ну вроде есть люди, пишут, даже архимаг советует в каждом первом треде за последние пару месяцев.

tensai_cirno ★★★★★
()
Ответ на: комментарий от archimag

>Просто в Python такой код очень не удобно писать, а JavaScript легко.

Node.js неудобен. Хочется всё-таки код писать в «синхронном» стиле, с try/catch, циклами, линейным кодом. А уж рантайм/компилятор/ктоугодно пусть за меня переписывают/исполняют его асинхронно.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

Конечно хочется так, как ты написал. Но реально ли это? Я было кинулся на gevent, оказалось у него из-за хак-архитектуры случаются фейлы с некоторыми либами. Что остается - stackless python и tornado.

dizza ★★★★★
() автор топика
Ответ на: комментарий от dizza

фейлы с некоторыми либами.

а тебе какие либы нужны? Потом я сомневаюсь что stackless поможет в этом случае, а tornado это уже коллбэки, если не путаю.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Либы могут понадобится разнообразные. Фишка stackless по-идее в том, что он в отличии от gevent аккуратно со стеком поступает и ничего не ломается. Tornado - да, колбеки. Но зато либа с виду без премудростей и перформанс у нее хороший.

dizza ★★★★★
() автор топика
Ответ на: комментарий от dizza

Но зато либа с виду без премудростей

Из моего опыта написание сложный прог на коллбэках это адский ад. Реально если есть возможность использовать всякие stackless лучше так и сделать.

в отличии от gevent аккуратно со стеком поступает

погоди, ты где такое вычитал? Можно пример того что при этом ломается? Мне кажется ты сильно путаешь. Моё мнение он стэк не может поломать в силу хотя бы того что места в которых передаётся управление в хаб строго детерминированы. Поэтому библиотеки которые не задеваются monkey patching будут работать по-старому.

Да, есть вероятность что либы которые завязаны на socket итп поломаются. Но ты же знаешь свою задачу, ты должен представлять что надо а что нет.

true_admin ★★★★★
()
Ответ на: комментарий от WFrag

> Node.js неудобен. Хочется всё-таки код писать в «синхронном» стиле,

с try/catch, циклами, линейным кодом.


Смотри библиотеки Do и Step для Node.js.

archimag ★★★
()
Ответ на: комментарий от archimag

>Смотри библиотеки Do и Step для Node.js.

Отвратительно. Просто отвратительно. Как будто на ассемблере ОО программу пишешь. try...catch всё равно через одно место реализуется.

WFrag ★★★★
()

Хм. а мож QP как концепция будет интересна?

cvv ★★★★★
()
Ответ на: комментарий от true_admin

погоди, ты где такое вычитал?

Ну это я читал пост какого-то чувака. Он меня отправил за подробностями в каменты к gevent.c

dizza ★★★★★
() автор топика
Ответ на: комментарий от dizza

Он меня отправил за подробностями в каменты к gevent.c

Послал так послал :). Ну, начну с того что такого файла не существует. Единственный c-файл генерится через cython. Там ничего по слову stack не ищется. Может быть товарищ не прав? Поговори с ним :)

true_admin ★★★★★
()
Ответ на: комментарий от dizza

а, нашёл, но что там происходит не очень въезжаю. К сожалению тоже нет времени вникать. Я так понял что там хак который подменяет стэк питону при переключении нитей. Соответственно, всё грохнется если обратится к данным неактивной нити т.к. на месте её данных будут данные другой нити. Однако это не очень помогает понять какие библиотеки могут сломаться.

Всём вышеизложенное моя ламерская версия на основе прочтения http://stackoverflow.com/questions/3349048/how-do-greenlets-work, я хз так это или нет.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Однако это не очень помогает понять какие библиотеки могут сломаться.

Я что-то краем уха слышал про колбеки в обертках над сишными либами.

dizza ★★★★★
() автор топика
Ответ на: комментарий от dizza

Это, в принципе, логично. С другой стороны gevent это обёртка над libevent, и там всё работает. Короче, тут или разбираться до конца или забить и смотреть что на конкретную библиотеку. Если будет время я напишу разрабам greenlet что они по этому поводу думают.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.