AB
мне сейчас вообще думается, что в коде генсервера не должно быть в явном виде манипуляций с данными, не связанными с процессами/мониторами/etc
Size: a a a
2020 March 13
AB
хрен с ним с каналом, есть один генсервер-воркер, и он должен быть одним, обрабатывая кучу разных по типам сообщений в порядке их поступления, и вот я хочу разделить их по типу
как обрабатывая? и почему он должен быть один?
ŹR
хрен с ним с каналом, есть один генсервер-воркер, и он должен быть одним, обрабатывая кучу разных по типам сообщений в порядке их поступления, и вот я хочу разделить их по типу
Ну если у сообщений есть типы, то в чем проблема разделить?
МЛ
он изменяет файловую структуру на диске, и мне позарез надо чтобы в один момент времени только один процесс ее изменял
МЛ
можно наверное и разные сделать, но тогда получается нужно как-то организовать блокировку
AB
ок, что нужно сделать, чтобы один процесс обрабатывал входящие ивенты, а второй - работал с диском?
МЛ
ок, что нужно сделать, чтобы один процесс обрабатывал входящие ивенты, а второй - работал с диском?
так оно так и сделано, но операции с диском - разные, и друг от друга зависят, и их много
ŹR
Вот пример: есть foo.bar, foo.baz и bar.baz
def handle_call(msg, from, state) do
case String.split(msg, “.”) do
[“foo” | command] -> Foo.handle_call(command, from, state)
[“bar” | command ] -> Bar.handle_call(command, from state)
end
end
def handle_call(msg, from, state) do
case String.split(msg, “.”) do
[“foo” | command] -> Foo.handle_call(command, from, state)
[“bar” | command ] -> Bar.handle_call(command, from state)
end
end
AB
А всё, что общее между модулями - унести в Utils
ŹR
Так сложно роутинг сделать чтоле...
AB
Так сложно роутинг сделать чтоле...
Да тут скорее "как бы не рефакторить всё, но сделать код попроще"
МЛ
я так понял из доков что handle_call потеряет сообщения, которые придут пока он висит раздумывая над сообщением? или я неправ? у меня потенциально долгие операции, и сейчас я их все отлавливаю castом и просто отправляю каст обратно когда готово
ŹR
я так понял из доков что handle_call потеряет сообщения, которые придут пока он висит раздумывая над сообщением? или я неправ? у меня потенциально долгие операции, и сейчас я их все отлавливаю castом и просто отправляю каст обратно когда готово
Где такое написано то? Конечно нет
AB
я так понял из доков что handle_call потеряет сообщения, которые придут пока он висит раздумывая над сообщением? или я неправ? у меня потенциально долгие операции, и сейчас я их все отлавливаю castом и просто отправляю каст обратно когда готово
Нет, не потеряет. Но есть нюансы всё же.
AB
В принципе, идея с кастом терпимая, некоторый запас на будущее есть
AB
А что там всё-таки на диске? Хотя бы, один файл или много?
МЛ
много, изменяется структура, это внешняя утилита будет делать
AB
много, изменяется структура, это внешняя утилита будет делать
А в коде типа параметры для неё собираются?
МЛ
ну например есть часть сообщений про то что нужно создать/переименовать/изменить структуру проекта, а также отдельно создать/переименовать/изменить отдельную подструктуру в проекте, и так далее вложенно. хочу отделить их по работе со структурой/подструктурой/подподструктурой
МЛ
и получается в канал приходит сообщение, в его handle_in, и если я вызову там долгий call, получается этот handle_in подвиснет пока call не вернется