Чат на Erlang и Web Sockets
Данный чат в первую очередь задумывался как демонстрационный пример для моего доклада про веб сокеты на РИТ-2010. То есть в первую очередь он создавался чтобы протестировать веб сокеты, проверить как будет работать event-driven система, состоящая из брауера, сервера и среды передачи данных. То, что это все хорошо работает по отдельности - уже давно
( Read more... )
> Этих вот unicode:XYZ функций не надо вовсе. Смысла в них ноль.
Я попробую по вашей рекомендации все перенести на бинари. Здесь у меня просто часть операций делалась со списками, а часть с бинари, поэтому приходилось конвертировать.
> Conn_Manager = spawn(fun() -> conn_manager() end),
> Conn_manager = spawn(fun conn_manager/0),
В первом случае мы забиваем память анонимной функцией?
> erl -man gen_server, уверяю, это просто для головы, и лучше для дела.
Что-то он у меня не лезет в голову :)
Непонятен вот такой момент - у меня будет некое глобальное состояние сервера (State), которое будут получать мои callback`и. То есть, все, что сейчас раскидано и хранится в отдельных процессах будет храниться в единой переменной. Не станет ли от этого программа хуже работать? По идее должна испортиться асинхронность - т.к. все запросы должны будут работать с этой переменно и они будут вынуждены выстраиваться в очередь. Параллельно тоже будет обрабатваться один запрос?
Можно ли эту переменную разобраться на отдельные состояния? Например, если я добавлю поддержку нескольких комнат в чат, то мне нужно будет заводить несколько таких менеджеров клиентов. Мне как-то хочется держать их состояния отдельно, пусть в gen_server, но не в общей куче.
Почему-то я жду жутких тормозов, когда все процессы начнут копаться в этой куче ради изменения пары полей.
> continue_work() ->
> receive
Это чудовищный хак - мне нужно было как-то демонизировать процесс, иначе он постоянно завершался. Я это сделал загнав его в вечный цикл с выходом по сигналу.
как это делается по человечески?
> Гораздо корректнее использовать erlang:monitor, и ловить 'DOWN', чем ловить 'EXIT' после выставления trap_exit. Так как erlang:monitor внизу и делается, рекомендую выбросить process_flag(trap_exit, true) вовсе из кода.
Ясно. идея была в том, чтобы при ошибке в нижележащих процессах conn_manager не упал. В принципе link не используется, поэтому действительно trap_exit стоит выкинуть.
> Дикая позиционщина. Что за "2"? Я бы весь блок внизу переписал так:
Согласен, потом вспоминать все индексы и править их по всей проге станет ужасом. От этого необходимо избавляться.
Скажите, а насколько быстр будет этот код? почему-то я жду, что он будет пробегать по всему списку проверять все элементы - O(N), а значит жду тормозов при больших списках.
Вот здесь мне как-то очень хочется использовать хеш или аналог, чтобы обратиться адресно к нужному элементу и получитить трудоемкость O(1).
> Не люблю эрланговский if, но здесь явно просится:.....
Ясно
> ...воспользоваться erl -man queue....
Изучу.
P.S.
После ваших комментариев я понял одну простую вещь и смешную вещь - я упорно пытаюсь писать на Эрланге императивно. "взять элемент" - "сделать то" - "положить на место".
Вобщем это все надо перепродумать и переписать с чистого листа.
Reply
Reply
Я тоже решил двигаться в сторону OTP, пока некоторые детали не ясны, но будем разбираться.
Reply
Reply
Поздно заметил ваш комментарий - сейчас вообще не бываю в ЖЖ.
Нет, сейчас не занимаюсь Erlang - все же слишком узкая и специфичная ниша. Лично мне сейчас Golang видится более перспективным.
Reply
Leave a comment