YS
раз проблемы нет - вообще хорошо)
Size: a a a
2021 January 07
MP
ну как, проблема-то есть как раз, segfault
KV
если подозрение, что он сначала коммитит, потом абортит
Эта ситуация может быть только если процедура коммита успешно коммитит и при этом вываливает эксепшен
KV
ну как, проблема-то есть как раз, segfault
А она точно здесь?
YS
Эта ситуация может быть только если процедура коммита успешно коммитит и при этом вываливает эксепшен
я думаю Миша об этом и говорит
YS
что есть небольшой шанс что будет именно так
YS
который воспроизводится на больших количествах только, в силу своей редкости
KV
Ну так надо в эту процедуру тогда смотреть и чинить
MP
нет, но она точно качается транзакций которые работают в асинках, которым сделали cancel
YS
нет, но она точно качается транзакций которые работают в асинках, которым сделали cancel
а
cancel отправляется в f?MP
cancel отправляется куда-то в withROTransaction
KV
Мб вручную попытаться сегфолт вызвать?
KV
Точнее как-то гарантировать, что произойдёт именно та ситуация, которая его якобы вызывает
MP
это очень плохо воспроизводимая штука, сейчас я меняю код, запускаю 20 процессов, жду час-два, как правило один из них падает
MP
надо попробовать гарантировать, да
MP
но пока "статистическим тестированием" точно установлено, что если убрать cancel, то проблема точно исчезает
TZ
А если есть, скажем, data Q a b = Q {blabla}, то как правильно позвать makeLenses?
makeLenses ''Q хватит?YS
тупое решение в голову приходит, но вроде может гарантировать, что отработает либо только коммит, либо аборт
MP
ну вот я тоже склоняют сделать commited <- IORef False и
что-то типа mask $ do { commit; atomicModifyRef }
что-то типа mask $ do { commit; atomicModifyRef }
MP
надо конечно qniksta про такое спрашивать