сигнал есть сигнал

в звуковом он диапазоне или в сверхзвуковом (ультра) - неважно

Кто работал с genstage, есть для вас такой вопрос:

К примеру, есть продьюсер, который генерирует ивент к примеру 1 минуту. И есть консьюмер который обрабатывает тоже 1 минуту потом этот ивент.

Я правильно понимаю, что после того как консьюмер получит свой деманд (к примеру 500), он будет 500 минут его обрабатывать и в это время продьюсер будет тупо ждать вместо того чтобы готовить новую пачку?
И потом, когда консьюмер скажет «дай ещё», теперь он будет 500 минут ждать пока продьюсер ему этот деманд подготовит?

В результате пайплайн будет работать в 2 раза дольше чем он мог бы...

Предвосхищая вопрос «как делать ивент целую минуту?» :

Http request в рельсу

Кажется я знаю, как это разруливать... Надо хранить в стейте деманд и отправлять ивент как только он негенериться, по одному, не ждя 500 пачки

Интересно, консьюмер начнёт разруливать у себя такой ивент, или будет у себя копить 500...

А вот порезать demand до одного не получается. Тогда будет те же 1000 минут, только не 500-500, а 1-1-1-1-1 и тд

Сложна сука... Кто бы книжку написал...

Продюсер может готовить новую пачку
Как минимум через Process.send_after что-то класть себе в стейт
А потом по деманду возвращать накопленные данные

Да но нет. А вдруг деманда не будет

Это как бы нарушение backpressure абсолютное

Если тебе нужно делать это по деманду, то как продюсер должен понимать сколько ему нужно данных нагеренить наперёд?

Суть в том, что если деманд постоянный, то в пайплайне все будут работать без остановки

Нет, не будет. Я же объяснил почему

По-моему нет, но я бы попробовал лично Валиму задать этот вопрос.

Вообще очень странно если это так)) там должен быть стейт на продюсере потому-то помню точно что если консумер отваливается, продюсер не просрет стейт

Наверное и аналогично продюсер подготавливает ивенты на перед

А иначе какой смысл?

Быть может деманд надо побольше указать ?