SZ
AE всё то же самое сделает, только быстрее и лучше :р
Size: a a a
2020 November 18
VO
Ну надо будет ещё nfound хандлить, очередь городить и т.д
нет
SZ
т.е. чтобы разные порты обрабатывались одновременно - мне нужно что-то для multi-threaded? А что?
AnyEvent::Fork хехехе
VO
очередь никакая не нужна
VO
а nfound тут только что бы время от времени печатать "думаю. не мешайте"
DF
т.е. чтобы разные порты обрабатывались одновременно - мне нужно что-то для multi-threaded? А что?
ну AE::Fork можно взять и наспавнить процессов обработчиков сколько надо
NK
ну AE::Fork можно взять и наспавнить процессов обработчиков сколько надо
но тогда у меня возникает проблема коммуникации между ними
NK
оно технически то именно форк?
SZ
но тогда у меня возникает проблема коммуникации между ними
Всё ещё давно придумано до тебя :)
DF
но тогда у меня возникает проблема коммуникации между ними
нет, AE::Fork дает возможности коммуникации с чайлдами
SZ
оно технически то именно форк?
Ну, в целом да
SZ
Но они пытались оптимизировать
NK
нет, AE::Fork дает возможности коммуникации с чайлдами
через AnyEvent::Fork::RPC ?
DF
оно технически то именно форк?
оно там вообще отдельный процесс поднимает, не уверен что там честный форк ибо запускать им можно вообще левый код
NK
но мне бы не между чайлдами, мне надо разные общие структуры данных расшарить, т.е. получается их будет проще выносить в какой-то редис
SZ
но мне бы не между чайлдами, мне надо разные общие структуры данных расшарить, т.е. получается их будет проще выносить в какой-то редис
++
SZ
Как раз хотел посоветовать
SZ
Ибо когда тебе перестанет хватать компортов одного терминала, можно будет в тот же редис писать с других
DF
через AnyEvent::Fork::RPC ?
как вариант. Я просто у чайлдов stdout перехватывал и думал что с этим делать. От задачи зависит
NK
А в случае AnyEvent::Fork - все уже существующие/объявленные структуры данных и всякие переменные наследуются/передаются? Я вижу только отдельную передачу файлхандлеров ->send_fh ($fh)