AN
Ринг буффекр нашел, но таки нужен не он, а именно FIFO
Size: a a a
2020 March 02
AN
Досад. На случай, если будет читать начальство. Юз-кейс такой. Есть канал на отправку, который нельзя ни в коем случае суспендидть (на входе железка). Также нельзя делать бесконечный канал потому что может быть ситуация, когда потребитель отвалился. Но хочется, что бы потребитель имел возможность "догнать".
AN
VP
А для чего именно такое поведение, что когда потребитель не успевает, сохраняются N старых событий, и одно последнее?
OY
Ринг буффекр нашел, но таки нужен не он, а именно FIFO
https://github.com/Kotlin/kotlinx.coroutines/pull/1716
вот кстати есть что-то похожее, что надо
вот кстати есть что-то похожее, что надо
VP
Можно было бы взять conflated, из него перекидывать в буфер, а уже оттуда вычитывать.
Но изначальная затея кажется странной.
Но изначальная затея кажется странной.
AN
А для чего именно такое поведение, что когда потребитель не успевает, сохраняются N старых событий, и одно последнее?
Н последних
VP
Н последних
В issue формулировка " evict last one, when new value arrives"
VP
То есть если потребитель встал, все события кроме последнего будут старыми
AN
В issue формулировка " evict last one, when new value arrives"
Имелось в виду oldest. Сейчас аоправлю
VP
А это разве не ring buffer в чистом виде?
AN
А это разве не ring buffer в чистом виде?
Ну да, но ринг буффер все хранит, а мне RandomAccess не нужен, достаточно очереди
VP
Ну да, но ринг буффер все хранит, а мне RandomAccess не нужен, достаточно очереди
Ну как всё, старое-то перезаписывается
VP
Но это не так уж и важно
AN
Ну как всё, старое-то перезаписывается
Все, в смысле доступ по индексу
AN
Но да, ринг буфер пойдет. Просто ринг буфер дороговат, а linked queue можно очень дёшево сделать.
VP
Почему не получается передать адаптер в качестве аргумента?
AL
Я не абсолютно уверен, но там не
out вместо in должно быть в setAdapter? (HolidayViewHolder наверное наследник ViewHolder, но не предок)