Мой код. И там честно говоря всё тоже против блокировок для записей в клик и редис всегда есть таймауты, есть логи ошибок и тоже есть проверка на контекст for { select { case <-b.ctx.Done(): b.log.Info("Receive done signal while try to flush events from buffer") return b.dump() default: if err := b.dump(); err != nil { b.log.Error("Error while dump events. Sleep and try again", zap.Error(err)) time.Sleep(time.Second) continue } return nil } }
Вот он код флаша) то бишь опять же for которые слушает и контекст и есть дефолт, если только где-то в b.dump() но там блин нет работы сканалами или мьютексами) там просто возьму все записи что успел накопить и скинь в кх, любая ошибка логируется)
@koziavka Тобишь будь ошибка в dump он бы её залогировал, если нет никаких ошибок то for должен прекратиться, и в случае чего сtx.Done() при дампе тоже мог бы перехватиться, но этого не происходит)
У меня была ситуация, когда горутины с бесконечным циклом без блокирующих операций просто захватывали все го-процессора и ожидающие горутины просто никогда не могли запуститься. Не может ли и тут случаться такое? Что го-процессор просто не может вставить точку разрыва в выполнение горутины бесконечной? Проверять можно установкой Sleep(1) в тело бесконечного цикла. Это позволит процессору отправить горутинку в очередь и перейти к другой. Если решит, то можно либо изменить архитектуру на более разумную, либо оставить так, что немного костыльно…
Вот он sleep в случае ошибки) Если ошбки не было то for просто оборвётся)
В любом случае тут канал контекста тоже слушается и если был сигнал отмены контекста то с default он должен бы был на него перепрыгнуть
Обсуждают сегодня