Комментарии 23
а где еще реализована подобная концепция легковесных тредов?
тока в stackless python видел
тока в stackless python видел
Когда-то видел упоминание о каком-то проекте на jvm, реализующем данную парадигму. Уж простите, не смог нагуглить.
По сути своей реализация процессов erlang является уникальной. Я не знаю других, достигнувших продакшен уровня.
По сути своей реализация процессов erlang является уникальной. Я не знаю других, достигнувших продакшен уровня.
Достигших продакшена вроде нет, но из работающих знаю
на java: akka.io/
и Common Lisp: common-lisp.net/project/erlang-in-lisp/ (да, недвусмысленное название)
на java: akka.io/
и Common Lisp: common-lisp.net/project/erlang-in-lisp/ (да, недвусмысленное название)
Fiber-ы в Ruby?
Haskell
Начав пользоваться легковесными потоками уже не могу от этого отказаться. Это жутко удобно.
Начав пользоваться легковесными потоками уже не могу от этого отказаться. Это жутко удобно.
Прочитал порядком статей и книжку по erlang-у, но не могу придумать для себя, чтобы такого написать и где бы его применить :(
Следующий раз понадобится сервер-демон — просто возьмите erlang.
HTTP/REST/Chat/websocket/EMail/Proxy сервер, особенно если ожидается большое число параллельных соединений и важна надежность…
Вон недавно видел статью где описывалось создание egitd — демона для обслуживания GIT репозиториев andrew.hijacked.us/by_keyword/328/egit
Вон недавно видел статью где описывалось создание egitd — демона для обслуживания GIT репозиториев andrew.hijacked.us/by_keyword/328/egit
Там, где нужна отказоустойчивость, где огромное число клиентов и «плохое» поведение одного из них не должно обрушить всю систему, плюс допускаем, что наш код не идеален — и со всем этим надо как-то жить в продакшене.
Как-то друг показал программу типа «Ping-pong» (клиент отсылает серверу строку «Ping», сервер должен прислать «Pong»), не помню из какой книги. Мне понравилось то, что занимала она меньше 40 строк. Я пообещал в ответ написать аналогию на C# до 50 строк… В общем, если не считать необрабатываемых исключений — уложился.
Но идейность и мощь Erlang-а очевидна. Вспомнить хотя бы Yams vs Apache.
Но идейность и мощь Erlang-а очевидна. Вспомнить хотя бы Yams vs Apache.
НЛО прилетело и опубликовало эту надпись здесь
Я проверял эту статью. У меня не получилось повторить. После 1500 коннекшенов т эрланг становился нестабильным и падал.
Считаю что эмпирическое правило что на одно ядро процессора ~1000 потоков работает для любых систем.
Выжимая больше всегда где-то в чем-то теряешь.
Считаю что эмпирическое правило что на одно ядро процессора ~1000 потоков работает для любых систем.
Выжимая больше всегда где-то в чем-то теряешь.
ну, например в win32 есть те-же самые fiber-ы. За одним исключением — логику переключения с фибера на фибер надо самому писать. Но ведь все её уже написали, надо только в сорцах покопаться, так? :)
А изоляция файберов друг от друга? А посылка сообщений? В каком-то смысле процессы Erlang-а довольно близки к объектам в ООП (в Смоллтолковском понимании). Это тоже стоит учитывать. Ну и вот пример с Fiber-ами из msdn: msdn.microsoft.com/en-us/library/ms686919(v=vs.85).aspx. Стоит ли пробовать выразить то же самое на Erlang, чтобы проверить, что в случае win32 эта затея не имеет особого смысла?
Кстати, есть ли аналоги отладочных системных утилит для Erlang с GUI не на TK? Уж больно страшно выглядят…
Ну а вообще напрямую работать с процессами в Erlang вряд-ли часто нужно. Все через модули OTP…
Ну а вообще напрямую работать с процессами в Erlang вряд-ли часто нужно. Все через модули OTP…
кстати да, начинаешь знакомиться с erlang, читаешь про сообщения, процессы и думаешь вот сейчас буду делать spawn все дела.
а потом садишься писать и только handle_call() выходят сплошные :)
а потом садишься писать и только handle_call() выходят сплошные :)
Да есть, toolbar:start() — тулбар со всеми инструментами. Отладчик debugger:start(). Этим отладчиком ни разу не пользовался, просто не было надобности. В своих проектах в основном использую утилиты tv — если надо залезть в таблицы mnesia и appmon, чтобы посмотреть дерево процессов приложения.
По поводу прямой работы с процессами согласен, OTP супер. Просто чтобы понимать как там внутри все работает стоит все же поближе познакомиться с «сырыми» процессами.
По поводу прямой работы с процессами согласен, OTP супер. Просто чтобы понимать как там внутри все работает стоит все же поближе познакомиться с «сырыми» процессами.
Я правильно понимаю что только в Erlang реализована вытесняющая многозадачность для процессов виртуальной машины? Во всех остальных реализациях модели акторов (например в akka) вы не можете просто так взять и выполнить блокирующую операцию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Erlang и его процессы