Заводишь канал inFlightTx, пишешь в него все сообщения что надо посмотреть на предмет таймаута.


Раз в секунду горутина просыпается, вычитывает весь канал и то что не expired - закидывает в канал обратно

По факту, ты мапу не используешь по ключу примерно нигде

err := rows.Scan(...)
if err != nil {
    continue
}

https://play.golang.org/p/jSbqW-5TUuu вот полный код функции,ошибок нету,но и данных нет

Пока не понял мысль.
У меня постоянный поток запросов.
Тогда надо либо два канала с накоплением (но тогда таймер будет не настолько точно работать, правда у меня это не особо критично) и каждый раз переключаться между ними, либо в каком-то виде нужна в канале линия задержки, но такого я в Go не видел.

Но более интересно другое - а как я пойму, был уже ответ на такой-то seq (отправил ли я его уже) или не было?

Тем более, что кроме отслеживания таймаутов я в марте держу reference number'ы - мне пришёл ответ по сети, я его должен смаппить со входящим requestID, который хранится только у меня и в сеть я его никак не могу отправить (это когда мне запрос кинули в канал, я его отправил в сеть, получил ответ из сети и в другой канал вернул ответ).

У меня ключ в мапе нужен для обработки ответа, полученного по сети.

Т.е. основная задача мапы - трекинг запросов-ответов, хранение нужных данных, которые будут использоваться после получения ответа из сети.

А обработка таймаутов - способ чистить мапу от мусора в случае, когда по сети вовремя не ответили.
Либо когда из сети пришёл запрос, я его отдал в канал для обработки, но его никто не обработал.

Если я правильно понял, линия задержки без проблем делается на двух каналах, из одного в другой пересылать со слипом

запускать по горутине для задержки каждого отдельного сообщения?

А зачем, создали два канала, создали одну горутину, которая перекладывает из одного в другой. В один пишете, из другого читаете. Но тут надо будет ещё правильно закрытия отрабатывать

Тогда не понимаю.
Мне в канал кинули одновременно 100 запросов, через 30ms ещё 100 запросов.
Запросы идут последовательно, т.е. пришедший раньше раньше и должен выйти из линии задержки.

Горутина должна вычитывать заброс, брать из него время генерации и при необходимости делать sleep?

Каналы это уже FIFO очереди, так что кажется, что дополнительно ничего делать не надо

НО без задержки.
А сейчас говорим про то, что пакет должен стать доступным для чтения после какого-то fix времени с момента закидывания сообщения в канал.

buildings = append(buildings)

Так вы же здесь ничего не добавляете

млять...пиздец

извиняюсь...

@xfoby спасибо,уже замылился взгляд просто

Бывает)

Господа, после обновления голанда дропдаун с подсказками стал широкий как не в себя. Кто знает, это баг или фича, и можно ли как-то пофиксить/настроить?

На скриншоте он у меня вообще на соседнее окно уехал, так как одного ему мало

TabNine юзаешь?

Да