AP
но может
Size: a a a
2020 April 08
AK
1 процесс на кривую схему, можно форкать только когда реально попалась гадость, хотя можно и сразу. Ну и по количеству процов процессы на десериализацию в обычном случае
AP
1 процесс на кривую схему, можно форкать только когда реально попалась гадость, хотя можно и сразу. Ну и по количеству процов процессы на десериализацию в обычном случае
форкать? нельзя
VG
хабрастатью помню
примерно в 3 ночи мск 7 апреля сервер перестал что-либо выдавать, кроме bad msg раз в час, после перезапуска вечером минуту всё было хорошо, потом попёрли адовые стектрейсы :)
AP
1 процесс на кривую схему, можно форкать только когда реально попалась гадость, хотя можно и сразу. Ну и по количеству процов процессы на десериализацию в обычном случае
можно форкать только в смысле эниевент-форк
b
ну там в new() класса делается
внутри этого cb делаются unshift_read в зависимости от текущего состояния
$aeh->on_read( $self->_get_read_cb )
внутри этого cb делаются unshift_read в зависимости от текущего состояния
ну так это безусловная читалка, как я понял. Не пользуйся ей, если под твою задачу не подходит ), юзай
push_read , видимо.AP
ну там в new() класса делается
внутри этого cb делаются unshift_read в зависимости от текущего состояния
$aeh->on_read( $self->_get_read_cb )
внутри этого cb делаются unshift_read в зависимости от текущего состояния
в такой формулировке затруднительно, ты хочешь ещё один промежуточный уровень.
AK
можно форкать только в смысле эниевент-форк
Не суть важно. Просто сам подход другой. Тут проблема со сбором результатов от обработчиков в нужном порядке... для меня обычно в этом загвоздка
VG
ну, в идеальной теории я хотел бы заморозил весь "тред" и передал управление на другой
AP
ну, в идеальной теории я хотел бы заморозил весь "тред" и передал управление на другой
через коро?
AP
других способов заморозки нет
AP
заодно это решило бы вопрос сценария
VG
ну так это безусловная читалка, как я понял. Не пользуйся ей, если под твою задачу не подходит ), юзай
push_read , видимо.она прекрасно работает 360 дней в году :)
AP
в эниевенте очень хреново делать сценарии на колбеках. я делал на пое, там главным элементом выступает стейт, а не сокет
AP
к сожалению, мои наработки как делать подобное на эниевенте профуканы. ну и хрен с ними
VG
через коро?
не работал с ним, не знаю, поможет ли - плюс, я также держу в голове возможное развитие архитектуры, когда вот этот tcp-клиент сам находится в процессе-клиенте AnyEvent::Fork::RPC::Async
AP
не работал с ним, не знаю, поможет ли - плюс, я также держу в голове возможное развитие архитектуры, когда вот этот tcp-клиент сам находится в процессе-клиенте AnyEvent::Fork::RPC::Async
ну иначе нужен либо допольнительный слой, либо вообще центральным элементом делать стейты/треды, а что приходит из сокетов только инструкция для изменения стейта. и тогда можно им флажок "замёрзнуть" добавить
VG
не уверен, что автор либы примет настолько радикальный пулл-реквест :)
VG
в main, где и единственный condvar, я могу делать что хочу, конечно
b
Я что-то вообще не видел ивент-лупов, в к-х можно было бы "исключить" что-то временно из опроса.
Есть ивент-лупы, где отдельный инстанс Loop можно создать и крутить ТОЛЬКО ЕГО. Но тогда "замораживается" всё остальное. Это не то. В AE всё всегда крутится, и "исключать", афаик нельзя (а нужно "не включать", т.е. не делать
ВГ у тебя задача c гонками - пока ещё какой-то сторонний сервис опросишь, тебе от клиента всё равно могут данные уже прилететь. Не обрабатывать их можно только делая СИНХРОННЫЙ запрос (или не на AE-лупе). Выглядет как костыль для сервера
Есть ивент-лупы, где отдельный инстанс Loop можно создать и крутить ТОЛЬКО ЕГО. Но тогда "замораживается" всё остальное. Это не то. В AE всё всегда крутится, и "исключать", афаик нельзя (а нужно "не включать", т.е. не делать
push_read). ВГ у тебя задача c гонками - пока ещё какой-то сторонний сервис опросишь, тебе от клиента всё равно могут данные уже прилететь. Не обрабатывать их можно только делая СИНХРОННЫЙ запрос (или не на AE-лупе). Выглядет как костыль для сервера