a:=make(chan string) close(a) a=nil fmt.Println(a==nil) // true

a:=make(chan string) close(a) a=nil fmt.Println(a==nil) // true

Но ведь это не проверка на то, что канал жив :)

a:=make(chan string) close(a) a=nil fmt.Println(a==nil) // true

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

Но ведь это не проверка на то, что канал жив :)

Мы сказали каналу закрыться, какие у него шансы на выживание?

Мы сказали каналу закрыться, какие у него шансы на выживание?

Я бы вообще не парился, и просто оставлял их открытыми, GC сам все подберет

Нельзя

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

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

и чо ?

и другая горутина закроется только если канал закрыл

и другая горутина закроется только если канал закрыл

ну дык делай в другой горутине: for v := range ch {}

или через select

и чо ?

так оно и сделано через селект

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

так оно и сделано через селект

ну так темболее, тебе придет флаг, что канал закрыт

а всемте с ней еще несколько соединений

ну так темболее, тебе придет флаг, что канал закрыт

Блин, мне надо проверить закрытие канала со стороны

Канал сделай структурой, где создай флаг: будет - закрыто/открыто

если юзер перелогинивается, надо старые каналы закрыть, новые огранизовать на их место

Если поверх перезаписать новые, то gc старые не закроет и память поедет

если юзер перелогинивается, надо старые каналы закрыть, новые огранизовать на их место

Не вижу проблемы, делаешь всем им close() и запускаешь новые

^this

Не вижу проблемы, делаешь всем им close() и запускаешь новые

ЗБС А то я не догадался, от делать нечего тут вопрос пишу, а если канал уже закрыт? то паника, надо либо проверять канал на закрытость, либо отлавливать панику

Блин, мне надо проверить закрытие канала со стороны

Никак, только менять архитектуру приложения

ЗБС А то я не догадался, от делать нечего тут вопрос пишу, а если канал уже закрыт? то паника, надо либо проверять канал на закрытость, либо отлавливать панику

ну и хрен с ней, с паникой. recover же есть

не, ну это не ок

не, ну это не ок

он изначально чухню написал, хуже не будет )

он изначально чухню написал, хуже не будет )

Это говорит человек который предложил оставлять каналы на волю gc ?

ЗБС А то я не догадался, от делать нечего тут вопрос пишу, а если канал уже закрыт? то паника, надо либо проверять канал на закрытость, либо отлавливать панику

ну так сделай флаг a.isClose = true и проверяй, перед тем как в канал слать

ну так сделай флаг a.isClose = true и проверяй, перед тем как в канал слать

Про слать разговора вообще небыло

Про закрытие был вопрос, уже нет

то, что канал спавнит, должно его закрывать

producer should close the channel

если не так - косяк в дизайне

КЭПство. Понятно что он должен быть закрыт, но он может быть закрыт из нескольких мест, по этому при закрытии нужно проверит, а не закрыт ли он ранее

Это говорит человек который предложил оставлять каналы на волю gc ?

Я тебе больше скажу - так много где написано https://stackoverflow.com/questions/8593645/is-it-ok-to-leave-a-channel-open Закрытие канала лишь информирует горутину которая слушает, что больше данных не будет :) Если у тебя так получется что закрытие каналов может быть вызвано несколько раз для одного и того же ... ну, это уже твой косяк :)

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

КЭПство. Понятно что он должен быть закрыт, но он может быть закрыт из нескольких мест, по этому при закрытии нужно проверит, а не закрыт ли он ранее

^this, сделай одно место

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

У нас завершается приложение надо закрыть все каналы? НАДО! Если в этот момент приходил логаут, в горутину, которая еще не завершилась, по сценарию надо закрыть канал. Вероятность совпадения этих двух факторов мала, но произошло на практике.

https://play.golang.org/p/CEO_flcINB

делайте закрытие значит тоже с помощью quit-канала

а эвент в него посылайте уже из функций

неважно какой - завершения приложения, или релогина

будет одна точка закрытия тогда

капец костыли (

капец костыли (

А вот, ниразу. Очень даже goway :)

by design так

сцуко, говэй, улыбнуло, вспомнилось питониквэй, где явное, лучше, чем не явное ???

сцуко, говэй, улыбнуло, вспомнилось питониквэй, где явное, лучше, чем не явное ???

Можем еще вспомнить perl way ... там вариаций много больше ;))

ну и в целом, касательно первого вопроса про утечку памяти, ничего не потечет

GC чистит неюзанный канал в любом случае, открыт он или закрыт

ну и в целом, касательно первого вопроса про утечку памяти, ничего не потечет

Канал не закрыт, горутина работает, в горутине живет WS соединение

Ребят, кто какую аналитику использует в го?

Канал не закрыт, горутина работает, в горутине живет WS соединение

если уж горутина не закрылась, это да

GC чистит неюзанный канал в любом случае, открыт он или закрыт

Как он его почистит, если его горутина читает?

уточнил

если уж горутина не закрылась, это да

А горутина закрывается, когда канал закрывается

¯\_(ツ)_/¯

Ребят, кто какую аналитику использует в го?

смотря что имеется в виду

close(a) a=nil Самый что ни наесть юзер фрэндли вариант получился

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

У нас завершается приложение надо закрыть все каналы? НАДО! Если в этот момент приходил логаут, в горутину, которая еще не завершилась, по сценарию надо закрыть канал. Вероятность совпадения этих двух факторов мала, но произошло на практике.

что значить НАДО???

вариков полно

что значить НАДО???

Надо корректно завершить сервер, закрыть все соединения, скинуть всю инфу в базу.

на прошлом месте юзали отправку эвентов в InfluxDB и смотрели через Grafana

сейчас через NewRelic

https://opensource.googleblog.com/2018/01/opencensus.html вчера выкатили. но это чуть другое. это метрики перфоманса а мне еще пользовательские ивенты нужны

ERROR: S client not available

о нюрелик)))

логи через Kibana

у меня мой проект поэтому позволить себе нюрелик не могу но вообще история прикольная

инфлюкс с графаной вполне себе варик

и настраивать не особо сложно

хотя графана умеет много сорсов http://docs.grafana.org/features/datasources/

ага заценю, спасибо!

инфлюкс с графаной вполне себе варик

У меня сейчас так же. Еще и графит даже есть :)

http://blog.egrik.ru/2016/01/influxdata-1-influxdb.html а тик стэк кто-то использовал,

?

у нас щас тик

ненавижу его)

графана удобнее?

тик постит эвенты в ньюрелик

а

стоп

не тот тик, проехали

подумал, что речь про https://github.com/TykTechnologies/tyk

графана удобнее?

Графана - это просто морда. Сами же метрики собирает тик\графит\другая хрень

Графана - это просто морда. Сами же метрики собирает тик\графит\другая хрень

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

только с графаной

а чо с прометеем? кто-то использовал? https://prometheus.io/docs/introduction/comparison/

а чо с прометеем? кто-то использовал? https://prometheus.io/docs/introduction/comparison/

перешли с инфлюкса на прометеус

перешли с инфлюкса на прометеус

и как впечатления?

я так понимаю он сильно навороченнее

и как впечатления?

ну как я помню девопсы говорят перфоманс лучше при тех же затратах, ну и да, всякие плюшки с типами (целых 4! насколько я помню), polling моделью и прочим

капец костыли (

Пора осилить context

Это говорит человек который предложил оставлять каналы на волю gc ?

Каналы прекрасно собираются сборщиком точно так же, как и все остальное. Просто проблема с каналами, что где-то чтение может заблочить горутину и она как зомби будет вечно висеть, а канал вместе с ней. Но в таких случаях для совсем упорных можно обернуть каналы в структуру, а туда какой-нить метод close(), и установить финализатор, чтобы наверняка!

ну как я помню девопсы говорят перфоманс лучше при тех же затратах, ну и да, всякие плюшки с типами (целых 4! насколько я помню), polling моделью и прочим

спасибо прояснилось!

Каналы прекрасно собираются сборщиком точно так же, как и все остальное. Просто проблема с каналами, что где-то чтение может заблочить горутину и она как зомби будет вечно висеть, а канал вместе с ней. Но в таких случаях для совсем упорных можно обернуть каналы в структуру, а туда какой-нить метод close(), и установить финализатор, чтобы наверняка!

звучит как анальная боль

спасибо прояснилось!

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

ага но он стек не сохраняет? хочу попробовать opencensus сейчас пользуюсь фришным stackimpact