Канал должен быть открыт всегда, просто не закрывай его, когда нужно GC сам все уберет

Есть случаи когда канал закрывать нужно

подскажите, как правильно проверить открыт ли канал в горутине, которая в этот канал должна отправлять данные? if _, ok := <-cOrder; ok {} ждёт когда в канал что-то пошлют, что не подходит по логике

Да, частные случаи есть. Но общий подход таки это не закрывать каналы, ИМХО

Канал должен быть открыт всегда, просто не закрывай его, когда нужно GC сам все уберет

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

сделайте структуру, а в ней канал и "флажочек" closed и проверяйте его, только "прикройте" его чтоб не поломалось все при конкурентном доступе

for a,b := range ch {} не?

а какое будет поведение при открытом канале? по-моему, так же ждать

Видимо, Я не так понял задачу :)

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

Хм... а почему бы тогда в этом сообщении не добавить указатель на канал, куда отправить ответ ?

нету такой информации. в сообщении есть ID и Status, горутина которая занимается приёмом сообщений не знает чьё оно, оно просто должно при статусе ERROR отправить в канал, чтобы горутина разобралась её ошибка или не её, по ID. горутины может не быть на месте, значит ошибку сгенерировала не она, а пользователь

Т.е. переслать это же сообщений обратно отправителю, да?

советую почитать про select - https://tour.golang.org/concurrency/5

select { case ch <- something: default: // cannot send to ch, do something else here }

подскажите, как правильно проверить открыт ли канал в горутине, которая в этот канал должна отправлять данные? if _, ok := <-cOrder; ok {} ждёт когда в канал что-то пошлют, что не подходит по логике

я сам только спустя большой такой промежуток начал понимать их хД

а битовые операции у вас есть в программе?

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

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

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

у меня машина на 128мб озу

а вы их как переменные окружения передавайте, а так, если по памяти все сложно, то Go это достаточно спорный выбор

возьмите https://github.com/go-yaml/yaml и не парьтесь

возьмите https://github.com/go-yaml/yaml и не парьтесь

зачем? есть стандартный жсон по функционалу такой же и ничего не надо со стороны брать

стандартный жрет как не в себя

стандартный жрет как не в себя

еще такая штучка есть https://github.com/json-iterator/go

есть сравнение?

еще такая штучка есть https://github.com/json-iterator/go

Это очень как дофига

стандартный жрет как не в себя

если действительно хотите съэкономить на сериализации конфига, binary/encoding binary/decoding Вам в помощь

Идея неплохая но проблема в том что конфиг надо руками править если бы не это обстоятельство Я бы прямо в бинарник записывал

если Вам не хватает 128 мб, то я сомневаюсь, что замена стандартного парсера жсон на маргинальный решит проблему. И не думаю что стандартный парсер будут кардинально меньше мозгов забирать, скорее больше проц грузить рефлексивными вычислениями.

сделать фронтенд для правки конфига?

Да Go не самый лучший выбор когда у вас мало памяти но никто мне об этом не сказал когда начинали писать А сейчас уже выписывают но что-то другое время не особо нет

если действительно хотите съэкономить на сериализации конфига, binary/encoding binary/decoding Вам в помощь

Он в Go как раз более прожорлив чем гошный json

Да Go не самый лучший выбор когда у вас мало памяти но никто мне об этом не сказал когда начинали писать А сейчас уже выписывают но что-то другое время не особо нет

https://github.com/mailru/easyjson

какая ОС кстати?

linux x64 kernel 3.16