AP
теперь 100501
Size: a a a
2020 April 03
OP
Антон, подстраиваться под тот интерфейс, резона мало это потеря скорости работы и ухудшение имхо. Другие норм имена для модулей все заняты. Пришлось выбирать меньшее из зол
OP
Protocol::HTTP был по счастливому случаю свободен. С вебсокетом не повезло)
VG
да неймспейсов для протоколов вообще-то больше одного )
OP
Да но они сука все кривые. Перфекционизм он до могилы доводит))
AP
речь о замене существующего кода
OP
Я им страдаю
AP
перейти с не-иксес на -иксес реализацию не получается в такой схеме
OP
Потому что она другая полностью. Обычно там имплементят ровно тоже что написали на перле тока на XS. А тут под капотом вообще с++ фреймворк о перле знающий чуть больше чем ничего. И адаптер а нему
OP
Вернее чуть меньше
AP
я понимаю возможные причины. просто грусть. у меня есть фреймворк, где используется не-иксес модуль и мне не получится просто так взять и перейти на -иксес
AP
в общем, я рад, что появился новый модуль. больше возможностей хороших и разных.
OP
Да. Если бы у него другое имя было (в другом ns) ситуация бы не изменилась.
AP
Да. Если бы у него другое имя было (в другом ns) ситуация бы не изменилась.
но изначально надежды было бы меньше :)
OP
Хорошо. Ктонить может предложить пиздатое имя?)
AP
ладно, что уж теперь. я всё равно собирался переписать фв, там можно сразу иксес вариант взять...
OP
Позже будет выложен UniEvent::WebSocket
Это уже async к вебсокету.
Фишка в том что он использует протокол и unievent без вызовов через перл вообще, напрямую в с++
И потери нулевые, и чем выше башня тем скорость не падает на накладные расходы. Вобщем думаю 200к/сек по сети на 1 ядре потянет
Это уже async к вебсокету.
Фишка в том что он использует протокол и unievent без вызовов через перл вообще, напрямую в с++
И потери нулевые, и чем выше башня тем скорость не падает на накладные расходы. Вобщем думаю 200к/сек по сети на 1 ядре потянет
OP
Прямо из перла
OP
Если потоково то больше миллиона
OP
На 1 ядре