в реальных проектах не использовал

но вообще вроде норм либа

а unagi-chan по ходу дела просто очередь чистит лишь по получению след. сегмента

т.е. про быстрых ридерах памяти оказывается занято от 0 до (bound+delta)

хотя про дельту гоню

но суть в том, что даже при 0 доступных элементов почти вся очередь будет висеть в памяти, если читатель смотрит в конец её

и выглядит, что оно by design

хм.. а поподробнее?

дак а что подробней?

т.е. когда ты ридером реквестируешь себе слот, то это держит очередь?

очередь - массив

пишем в k-й элемент

читаем из него же

когда это k достигает размера очереди

делаем новый сегмент

а старый выкидываем

ну вот пока не достигли размера, сегмент висит себе и висит

а размер сегмента какой?

размер сегмента == размер очереди

т.е. 1 очередь в N элементов это бесконечный набор массивов размером в N

так.. чего-то это не то вроде..

в массиве data Cell a = Empty | Written a | Blocking !(MVar a)

ну то не то

там же сегментами, по 1024 элемента, разве нет?

вот пример, который нормально жрёт памят - https://gist.github.com/qrilka/1f7cd7c2254b0e267de77d3c61542d43

хотя ридер быстрей писателя

я сейчас про https://github.com/jberryman/unagi-chan/blob/master/src/Control/Concurrent/Chan/Unagi/Bounded/Internal.hs

там никаких 1024 не вижу, может какие-то более клёвые очереди уже куда-то завезли?

ну я разве что не bounded смотрел

sEGMENT_LENGTH

ладно, давай вечером посмотрю, а то я бегаю туда сюда все свою работу нормально сделать не могу

мне самому интересно

хотя вот странно на unagi например katip работает (правда у нас без него), при таком поведении было бы "все плохо"

я думал bounded - тупо кольцо

там вроде не совсем кольцо

так теперь мне интересно почему старые чанки не освобождаются

ну чанк рабочий типа

ну и с кольцом те же яйца вышлиб

очередь пустая, а данные не собираются GC

т.е. память не чистится

про кольцо тоже тикет есть https://github.com/jberryman/unagi-chan/issues/20

а в катипе вижу import qualified Control.Concurrent.STM.TBQueue as BQ

Они отказались от унаги вроде. Типа бенчи не показали значимости, но это не точно

https://github.com/Soostone/katip/commit/ff5ca3b7fe1c1ccb70af8feca6c3b127b1f27fa9

ага

Found in my tests that TBQueue seems to be performing better in this case than our use of unagi-chan. That, coupled with the more widespread use of STM was enough to convince me to switch. I'm guessing part of it is that unagi-chan is a chan, meaning it has broadcast features that we don't need.

https://github.com/haskell/stm/pull/2/files

про что я говорил

у нас катип вообще со своим handler-ом полностью

а он у вас в файл пишет?

т.е. криво работает и то и другое?

с релоадом?

вот жеж

@lonokhov stdout

Kirill пока - да

@lonokhov но когда не лень будет мы может на стандартный перейдем, там просто форматов вывода не очень поуправляешь

меня вымораживает что он целые пишет с точкой

а это всяким внешним ресурсам типа datadog/stackdriver надо, чтобы оно хорошо интегрировалось в их поиск теги и т.п.

типа 0.0, 1.0 вместо 0,1. чёртов scientific

ещё мне не нравится то, как они хранят value

я боюсь, что ЭТОТОРМОЗИТ

@qnikst но можнож с гитхаба stm собрать?

вот да

а stm не в зависимостях у ghc?

Kirill давно не продовал, мне казалось что оно вообще привязано к ghc

но точно не помню

вот bytestring точно менять можно, хотя оно и в зависимостях

эммм, блин

а ещё помни, что стек разрешает менять меньше, чем можно

ок, посмотрим

вроде нет

может попрыгать через кольца горящие придётся

не в зависимостях

@lonokhov нет == не в зависимостях ghc?

stm не распространяется с ghc

ghc зависит от stm: https://github.com/ghc/ghc/tree/master/libraries

а чего его в доках нет?

ну тогда беда

вроде для стэка это танец с бубном, с nix я даже не знаю.