выключить дебаг? ?

А как его выключить? ?

если не ошибаюсь

go build -ldflags "-s -w"

Спасибо. Можно ещё вопрос? [С чем это связанно] У меня не находит дебаггер gdb (когда стояла windows 8.1 у меня находило дебагер и дебажил код, а сейчас стоит windows 8.1 и дебагер не найден "'gdb' is not recognized as an internal or external command, operable program or batch file.") go version go1.10 windows/amd64

Причем в переменную среды я ничего тогда и сейчас не вписывал

под винду не знаю, увы

ладно, спасибо

анмаршалю xml, как проверить на отсутствие элемента(который `omitempty`), что бы не обращаться к его свойствам, что вызовет ошибку?

А есть какой-нибудь способ сделать что-то типа мягкого RLock к мьютексу? Типа попытаться сделать RLock, если мьютекс залочен то вернуть какой-то результат.

нет, нельзя

но можно написать свой такой мьютекс на атомиках

ну или найти такой готовый

Ага, погуглил уже, хотя пока гуглил, понял что оно мне и не особо то надо. )

коллективный самоответ :)

анмаршалю xml, как проверить на отсутствие элемента(который `omitempty`), что бы не обращаться к его свойствам, что вызовет ошибку?

Используй указатели, Люк!

Если nil - нет объекта

Используй указатели, Люк!

изи... спасибо, чот тупанул...

А нормально, что гошный race detector пишет, ворнинги на код внутри atomic.SwapUint64?

WARNING: DATA RACE Write at 0x00c42040d810 by goroutine 114: sync/atomic.SwapInt64() /usr/lib/go/src/runtime/race_amd64.s:254 +0xb

WARNING: DATA RACE Write at 0x00c42040d810 by goroutine 114: sync/atomic.SwapInt64() /usr/lib/go/src/runtime/race_amd64.s:254 +0xb

Покажите Read at

Не могу к сожалению, там много рабочего кода, но в readat он выдает функцию, внутри которой вызывается 2 раза другая функция, внутри которой atomic.AddInt64 на эту переменную (и вообще это приватное поле структуры, которое не читается нигде, кроме одного метода, где она только через atomic читается).

Не могу к сожалению, там много рабочего кода, но в readat он выдает функцию, внутри которой вызывается 2 раза другая функция, внутри которой atomic.AddInt64 на эту переменную (и вообще это приватное поле структуры, которое не читается нигде, кроме одного метода, где она только через atomic читается).

Как она у вас читается?

Вот строчка в которой read at (первая строка) https://pastebin.com/BjJHC1gc

А в write строчка reqs = atomic.SwapUint64(&r.reqcnt, 0)

Вот строчка в которой read at (первая строка) https://pastebin.com/BjJHC1gc

key?

_, err = redis.CounterIncr("key1."+key, 14*24*time.Hour) в read at

_, err = redis.CounterIncr("key1."+key, 14*24*time.Hour) в read at

Ну и где тут чтение через атомик?

Конечно у вас будет race condition

Ну там внутри CounterIncr вызывается функция в которой инкремент через atomic для r.reqcnt на своп которого ругается write

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

Ну там внутри CounterIncr вызывается функция в которой инкремент через atomic для r.reqcnt на своп которого ругается write

У вас проблема в Read at Нигде не видно atomic.Load...

Читается оно тут https://pastebin.com/bUi01yqD

reqs = atomic.SwapUint64(&r.reqcnt, 0)

И это единственное место, где оно читается.

И вот именно на это место и ругается во write

Выложите полный Warning Data Race

https://pastebin.com/HmFFss67 я пути только на *** заменил частично

/counters/counters.go:61 это как раз _, err = redis.CounterIncr("key1."+key, 14*24*time.Hour) а **/db/redis_main.go:24 это reqs = atomic.SwapUint64(&r.reqcnt, 0)

А содержимое CounterIncr я раньше присылал.

Вообще больше на false positive похоже, только непонятно почему, наверное забью пока на это. Я несколько раз код перечитал r.reqcnt снаружи читаться точно нигде не может, потому что приватное, а инкрементится оно только через atomic.AddUint64, просто странно.

Собственно вот весь модуль, внутри которого оно ругается, не знаю, где тут можно ошибиться https://pastebin.com/1vajH9S4

reqcnt и errcnt там больше нигде не используются

ребят, как реализовать подобный барьер: типа "дамбы" которая блокирует всех "читающих" до того, как не дёрнут шлюз.. дёрнули шлюз - все горутины которые ждали - проходят, после чего шлюз снова закрывается и снова блокирует

Вечер добрый. Я верно понимаю, что для того, чтобы отловить панику, нужно её ловить через defer в каждой запущенной горутине? Или достаточно в main.go прописать defer ?

ребят, как реализовать подобный барьер: типа "дамбы" которая блокирует всех "читающих" до того, как не дёрнут шлюз.. дёрнули шлюз - все горутины которые ждали - проходят, после чего шлюз снова закрывается и снова блокирует

ну - на каналах

вот тут, кстати, можно применить канал каналов :)

Вечер добрый. Я верно понимаю, что для того, чтобы отловить панику, нужно её ловить через defer в каждой запущенной горутине? Или достаточно в main.go прописать defer ?

если паника не будет словлена - он пойдёт вниз по стэку, таким образом её достаточно словить в самом нижнем, т.е. main

ребят, как реализовать подобный барьер: типа "дамбы" которая блокирует всех "читающих" до того, как не дёрнут шлюз.. дёрнули шлюз - все горутины которые ждали - проходят, после чего шлюз снова закрывается и снова блокирует

Можно через закрытие канала. закрыл канал: все горутины, которые его слушали, получили в закрытый канал nil.

ну - на каналах

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

Можно через закрытие канала. закрыл канал: все горутины, которые его слушали, получили в закрытый канал nil.

проблема в том, что потом его переоткрывать надо

в горутины передаем канал каналов

в горутины передаем канал каналов

честно говоря не понимаю

:)

создаёшь канал, по которому отправляешь не , скажем строки, а другие каналы.

chan chan struct{}

я не понимать ?

как из этого дамбу сделать

// block until background reconnection routine succeeds select { case err := <-clt.backgroundReconnection: // connected abort wait return err case <-time.After(timeout): // timeout, leave queue return webwire.ReqTimeoutErr{} }

вот тут все горутины ожидают пока шлюз (backgroundReconnection) откроется, либо пока им надоест и они сами выйдут с таймаутом

здесь я следственно закрываю канал close(backgroundReconnection) но проблема в том, что теперь то его переоткрывать надо...

его переоткрывать надо где-то в другом месте. там где шлюзом управляют.

переоткрыть канал нельзя

можно только новый подсунуть

и тут начинается геморой... это считай его нужно мьютексом защитить, но если рутины в очереди на него обретают shared lock то задедлочит горутина которая переоткрывает канал...

ERROR: S client not available

всё верно

вот что

не надо защищать

нам нужен атомик :)

ща, я набросаю экзампл

не надо защищать

как не надо?! это читать и писать в канал - thread safe, а вот мутировать reference канала то надо синхронизировано

вообще да, ещё один канал считать не выйдет. его же все считать придётся...

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

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

здесь мы не каналом пользуемся, а переменной указателем на канал, которая никак не защищена от concurrent read/write

с атомиком ждать не получится нормально

нужен ред-райт лок. Пока Lock() - все ждут. как сделали Unlock() , так все ждущие смогли взять Rlock() и потом соотвественно Runlock() по завершению делают.

потом как все сделали Runlock() , так дамба может закрыться , сделав Lock()

нужен ред-райт лок. Пока Lock() - все ждут. как сделали Unlock() , так все ждущие смогли взять Rlock() и потом соотвественно Runlock() по завершению делают.

так я-ж уже написал, что это dead'лочит... т.е. для чтения из канала нам нужно получить shared lock, а для его "переоткрытия", т.е. пересоздания - exclusive lock, который невозможно обрести, когда в очереди уже ждёт "горутинная вода"

так тебе из дамбы надо выпустить всю воду или как?

так тебе из дамбы надо выпустить всю воду или как?

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

т.е. шлюз не закрывается (exclusive lock нужен) когда в него вода бьёт, ибо у воды shared lock

т.е. ты видимо в цикле берёшь Rlock(), а тебе надо взять его один раз и потом ждать, что все его взяли и отпустили, что делается через WaitingGroup

постой, это как?

waitgroup то тут чем полезен?

в горутинах: wg.Add(1), mu.Rlock() , делаем что-то, mu.Runlock() , wg.Done(), wg.Wait() . в управляющей дамбой: for{ mu.Lock(), накапливаем, mu.Unlock() }

когда сработает последний mu.Runlock(), то найдётся ждущий mu.Lock() и он выполнится. Хотя я не даю 100% гарантии, что будет именно так всегда.

надо смотреть код Runlock. Он или передаёт управление горуитине ждущей лок или просто флажок снимает, что лок можно поставить. Но мне помнится, что передавал.

@onokonem , как считаешь?

wg и mu - в дамбе и горутинах одни и те же, если чё.

@onokonem , как считаешь?

пока ужинал - именно это и придумал :)

только зачем нужен лок?

у меня после еды наоборот башка отключается ?

wg сама справится

лок - чтобы все вместе стартовали.

в горутинах for{ wg.Add(1) // делаем что-то wg.Done() wg.Wait() } в дамбе: wg.Add(1) for{ wg.Done() // открываем дамбу wg.Wait() wg.Add(1) // закрываем дамбу // наполняем дамбу } wg.Done()

ты прав, лок не нужен.