a
Разве удобно гвозди забивать микроскопом?
Тут наоборот, речь о проведении нейрохирургической операции с помощью гвоздя и лупы.
Size: a a a
2020 December 16
VO
А зачем?
а затем что как чуть что-то сложнее линейного кода -- получается жопа.
SZ
allter
Тут наоборот, речь о проведении нейрохирургической операции с помощью гвоздя и лупы.
Tcp достаточно просто пишется в синхронной модели, он прост как полено (я реализовывал частично). Асинхронность для его реализации не нужна. И по-моему, как раз она -- микроскоп для забивания гвоздей.
SZ
а затем что как чуть что-то сложнее линейного кода -- получается жопа.
Вопрос выбора инструмента
VO
allter
Я выше упомянул, что это можно написать, но кроме алгебры промисов придётся использовать ещё кучу вещей для ресурсобезопасности. В любом случае, на голом AnyEvent это вообще нереально сделать так, что бы это было понятно/отлаживаемо.
Ну а для нормальной композабельности, придётся всё-таки переходить на нормальные монадки IO/Stream (которые в сути своей - функциональные FSM), и мириться с тем, что в процессе их работы они делают кучу аллокаций. Т.е. выбор - либо производительность, промисы и страдания с отладкой и пониманием этого, либо чёткое понимание, но куча вещей в хипе.
Ну а для нормальной композабельности, придётся всё-таки переходить на нормальные монадки IO/Stream (которые в сути своей - функциональные FSM), и мириться с тем, что в процессе их работы они делают кучу аллокаций. Т.е. выбор - либо производительность, промисы и страдания с отладкой и пониманием этого, либо чёткое понимание, но куча вещей в хипе.
ну окей, давай на tcp на монадках.
SZ
То, что ты предлагаешь -- сродни предложению написать ядро на haskell (не сомневаюсь, что такое уже есть, но разве это удобно..?)
b
allter
Я выше упомянул, что это можно написать, но кроме алгебры промисов придётся использовать ещё кучу вещей для ресурсобезопасности. В любом случае, на голом AnyEvent это вообще нереально сделать так, что бы это было понятно/отлаживаемо.
Ну а для нормальной композабельности, придётся всё-таки переходить на нормальные монадки IO/Stream (которые в сути своей - функциональные FSM), и мириться с тем, что в процессе их работы они делают кучу аллокаций. Т.е. выбор - либо производительность, промисы и страдания с отладкой и пониманием этого, либо чёткое понимание, но куча вещей в хипе.
Ну а для нормальной композабельности, придётся всё-таки переходить на нормальные монадки IO/Stream (которые в сути своей - функциональные FSM), и мириться с тем, что в процессе их работы они делают кучу аллокаций. Т.е. выбор - либо производительность, промисы и страдания с отладкой и пониманием этого, либо чёткое понимание, но куча вещей в хипе.
Тут согласен. Я выбираю промисы, иначе там ад из колбэков, не суппортабельный.
VO
Tcp достаточно просто пишется в синхронной модели, он прост как полено (я реализовывал частично). Асинхронность для его реализации не нужна. И по-моему, как раз она -- микроскоп для забивания гвоздей.
ну давай, показывай.
ну и что ты имеешь ввиду что асинхронность не нужна? там же вся суть в том, что прилетае с разных сторон асихронно пакеты, сисколы и таймеры.
ну и что ты имеешь ввиду что асинхронность не нужна? там же вся суть в том, что прилетае с разных сторон асихронно пакеты, сисколы и таймеры.
VG
Tcp достаточно просто пишется в синхронной модели, он прост как полено (я реализовывал частично). Асинхронность для его реализации не нужна. И по-моему, как раз она -- микроскоп для забивания гвоздей.
да прям уж, прост... одна фрагментация чего стоит
VO
То, что ты предлагаешь -- сродни предложению написать ядро на haskell (не сомневаюсь, что такое уже есть, но разве это удобно..?)
я не понимаю сути твоего возражения.
tcp все-таки на fsm проще или что?
tcp все-таки на fsm проще или что?
a
Tcp достаточно просто пишется в синхронной модели, он прост как полено (я реализовывал частично). Асинхронность для его реализации не нужна. И по-моему, как раз она -- микроскоп для забивания гвоздей.
Асинхронность тут нужна, что бы обслуживать большое количество tcp соединений. Но при этих соединениях тебе нужно безопасно обрабатывать события типа таймаутов. Напомню, что 1 сокет - это 1 файловый дескриптор. Их на современных серверах рекомендуют делать много, но их количество всё равно конечно. И при реализации работы с tcp асинхронно тебе надо в правильной последовательности забирать и отдавать сокеты в систему.
К слову, например, если при работе RabbitMQ исчерпать количество дескрипторов в системе, то кролик распухает и в конечном результате происходит OOM. Казалось бы, какая связь между файловыми дескрипторами и памятью. :)
К слову, например, если при работе RabbitMQ исчерпать количество дескрипторов в системе, то кролик распухает и в конечном результате происходит OOM. Казалось бы, какая связь между файловыми дескрипторами и памятью. :)
VG
если хочется сделать простенький tcp-like протокол (например как uTP в торрентах) в юзерленде, можно и без FSM обойтись - правда проще это будет сделать в виде примерно как AnyEvent отдает
SZ
я не понимаю сути твоего возражения.
tcp все-таки на fsm проще или что?
tcp все-таки на fsm проще или что?
У меня нет никаких возражений. Просто я считаю реализацию tcp в императивном синхронном стиле более удачной, чем «с использованием хипстерских технологий»
VO
я не понимаю что ты имеешь в виду "в синхронном стиле".
VO
там после пакета или чанка данных от приложения надо отдасться. это уже не синхронно. и точки входа типа разные
SZ
allter
Асинхронность тут нужна, что бы обслуживать большое количество tcp соединений. Но при этих соединениях тебе нужно безопасно обрабатывать события типа таймаутов. Напомню, что 1 сокет - это 1 файловый дескриптор. Их на современных серверах рекомендуют делать много, но их количество всё равно конечно. И при реализации работы с tcp асинхронно тебе надо в правильной последовательности забирать и отдавать сокеты в систему.
К слову, например, если при работе RabbitMQ исчерпать количество дескрипторов в системе, то кролик распухает и в конечном результате происходит OOM. Казалось бы, какая связь между файловыми дескрипторами и памятью. :)
К слову, например, если при работе RabbitMQ исчерпать количество дескрипторов в системе, то кролик распухает и в конечном результате происходит OOM. Казалось бы, какая связь между файловыми дескрипторами и памятью. :)
Сегодня у меня нет времени отвечать, но конкретно тут я много с чем не согласен
VO
плюс таймацты на ресенды и закрытие. что тут понимается под "синхронно"?
SZ
там после пакета или чанка данных от приложения надо отдасться. это уже не синхронно. и точки входа типа разные
То, что ты говоришь -- называется cooperative multitasking и не имеет отношения к асинхронности
VO
ну значит мы по-разному понимаем этот термин.
VO
по мне так типичная реализация tcp совершенно асинхронна хоть и кооперативна.