ну с английским конечно не на ты, стараюсь на русском искать инфу где это возможно

вот это зря. На русском, как правило, устаревшее гумно

или просто кривой перевод

да если честно нифига не понятно, вообще их избегаю все через мутексы делаю

Смотри, на пальцах: Каналы бывают буферизованные и небуферизованные. Сначала про вторые:

Фактически, это значение нужного тебе типа. 1 шт.

я читаю на английском, но не так комфортно как на русском, не родной язык и все

Поддерживается 2 операции: сунуть и вынуть.

при этом явно Lock делать не надо

сунуть я понял а вот когда и где и как их вытаскивать не понял

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

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

вот конструкция select зачем

это если рутина хочет пропалить несколько каналов, не всунул ли кто в один из них

вот ради теста накатал

в конкретно этом случае, проще for val := range ch

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

select нужен для неблокируещего чтения из канала

короче, смотри: 2 канала. В один суются сообщения, а во второй - команды "прекратить фигню"

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

я так понял конструкция select нужна если каналов больше чем 1?

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

я так понял конструкция select нужна если каналов больше чем 1?

в общем и целом - да

у меня была следующая ситуация которую я сделал с помощью мутексов было 3 запроса к БД в одной функции, они никак не связаны между собой ни на что не влияют, вот такую ситуацию можно было реализовать через каналы или нет? по сути простой асинхронный вызов 3х функций

ch1 := make(chan string) ch2 := make(chan string) go func() { for { ch1 <- "Hello1" } }() go func() { for i := 0; i < 10; i++ { ch1 <- "Hello2" } }() go func() { for { select { case msg := <- ch1: fmt.Println(msg) case msg := <-ch2: fmt.Println(msg) } } }()

вот на такие случаи селект нужен

у меня была следующая ситуация которую я сделал с помощью мутексов было 3 запроса к БД в одной функции, они никак не связаны между собой ни на что не влияют, вот такую ситуацию можно было реализовать через каналы или нет? по сути простой асинхронный вызов 3х функций

если хочешь дать в разных горутинах 3 запроса, подождать, пока они все 3 отстреляются, а потом уже что-то посчитать, есть такая штука, как sync.WaitGroup

select ещё нужн для таймаута чтения из канала

запустил, бесконечный цикл и выполняется только 1я рутина вернее 2я где (Hello 1)

если хочешь дать в разных горутинах 3 запроса, подождать, пока они все 3 отстреляются, а потом уже что-то посчитать, есть такая штука, как sync.WaitGroup

ну да я попутал насчет мутексов, через waitgroup и делал

запустил, бесконечный цикл и выполняется только 1я рутина вернее 2я где (Hello 1)

не совсем так. Там Hello2 стреляет 10 раз и завершается. Hello1 продолжает фигачить. Без селекта оно 10 раз отработает, а потом сдохнет на ожидании Hello2

ну да я попутал насчет мутексов, через waitgroup и делал

внутри WaitGroup - буферизованный канал

или вру?

не, это в ограниченных очередях буферизованный канал

ну спасибо, вот теперь бы найти в чем их применить и где))))

я запоминаю только из под практики, теория в моей голове ветренна)))

ну спасибо, вот теперь бы найти в чем их применить и где))))

допустим, ситуация, когда очередей событий более 1

смотри, представляем такую конструкцию:

у тебя 3 источника событий

каждый из них - черный ящик, из которого наружу торчит только канал строк

допустим источников 3:

1. таймер, посылающий событие раз в 10 секунд

2. таймаут, который через полчаса должен сказать "конец всему, закрываемся"

3. чат, из которого сыплются сообщения

все их надо отработать в одной функции

func workWithChannels()

каналы timerChan, timeoutChan, chatChan

берем в лоб: for { fmt.Println(<-chatChan) // сообщение из чата в stdout <-timerChan //дожидаемся сработки таймера fmt.Println("10 sec") if <- timeoutChan {//дожидаемся таймаута panic() //жоско выходим } }

первая инструкция кладет рутину в слип, пока с чата не придет сообщение. Т.е., пока кто-то тебе не напишет, событие от таймера ты не отработаешь, команду "выйтинах" рутина не увидит

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

третья вообще говорит: отработай одно сообщение, выжди 10 секунд и спи, пока не скажут "рабочий день окончен"

вероятно в изначальной логике такое поведение не планировалось)

спасибо большое за разъяснение, сново появился стимул дальше утить go))

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

“How to Turn an Android Device into a Web Server” @MakisMaropoulos https://medium.com/@kataras/how-to-turn-an-android-device-into-a-web-server-9816b28ab199

От известного в узких кругах Gerasimos'a

aka Kataras'a

Продвигает Iris как может :)

Всем привет, скажите, у всех при отладке кода в phpstorm с плагином go от jetbrains постоянно происходят скачки курсора в разные участки кода? например цикл работае тс переменной, происходит скачек на место где эта переменная объявлена,

Всем привет, скажите, у всех при отладке кода в phpstorm с плагином go от jetbrains постоянно происходят скачки курсора в разные участки кода? например цикл работае тс переменной, происходит скачек на место где эта переменная объявлена,

а зачем phpstorm когда есть gogland?

Всем привет, скажите, у всех при отладке кода в phpstorm с плагином go от jetbrains постоянно происходят скачки курсора в разные участки кода? например цикл работае тс переменной, происходит скачек на место где эта переменная объявлена,

Тоже такое наблюдал. Хотя видел отзывы, что хвалят дебагер.

а зачем phpstorm когда есть gogland?

Если честно, гогланд у меня тоже дебажит как кусок говна

Если честно, гогланд у меня тоже дебажит как кусок говна

дебажит? Ну так вопрос к дебагеру же )

они опенсорсный delve используют.

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

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

у меня гланды просто нормально работают )

у меня гланды просто нормально работают )

OS?

OS?

макось и линуксы

А что, atom.io не торт что ли? Я в нем пишу

А что, atom.io не торт что ли? Я в нем пишу

Я лично просто привык к продуктам JetBrains, потому что джавист

Я привык к vim и раньше писал в нем, в основном на python :)

Друзья, всем привет! Проводим тест php7 vs go. Тест заключается в следующем: * запрос к бд * вернуть результат То есть, ни авторизаций, ничего прочего. Просто sql запрос и вывод строки. Результаты следующие: на 1000 запросов php7 справился быстрее на 30%. Как такое может быть ? Пробовали в go держать одно соединение с базой - результат не изменился.

Друзья, всем привет! Проводим тест php7 vs go. Тест заключается в следующем: * запрос к бд * вернуть результат То есть, ни авторизаций, ничего прочего. Просто sql запрос и вывод строки. Результаты следующие: на 1000 запросов php7 справился быстрее на 30%. Как такое может быть ? Пробовали в go держать одно соединение с базой - результат не изменился.

Без кода никто ничего не скажет:)

наверное, код на C из php будет быстрее кода на Go

Без кода никто ничего не скажет:)

и еще конечно хотя бы тип БД

Может, из php запросы параллельно шли, а в go - последовательно. Ну и 4 ядра на машине:)

вы базу одну и ту же тестируете или разные? :)

наверное, код на C из php будет быстрее кода на Go

не должен .... , если нет замены транспорта (типа вместо TCP UDP)

и еще конечно хотя бы тип БД

MySql , но пытались замерить именно скорость языка. Думаю, можно сделать вывод, что и с другими БД будет аналогичная ситуация

вы базу одну и ту же тестируете или разные? :)

Одна и та же

есть подозрение, что без кода вам никто ничего не скажет.

Друзья, всем привет! Проводим тест php7 vs go. Тест заключается в следующем: * запрос к бд * вернуть результат То есть, ни авторизаций, ничего прочего. Просто sql запрос и вывод строки. Результаты следующие: на 1000 запросов php7 справился быстрее на 30%. Как такое может быть ? Пробовали в go держать одно соединение с базой - результат не изменился.

что за PHP?

MySql , но пытались замерить именно скорость языка. Думаю, можно сделать вывод, что и с другими БД будет аналогичная ситуация

Вы-таки померяли скорость взаимодействия с MySQL, а не скорость языка.

5 точно не быстрее го

что за PHP?

7.1.7

не должен .... , если нет замены транспорта (типа вместо TCP UDP)

Если локально, то вообще unix socket скорее всего

Друзья, всем привет! Проводим тест php7 vs go. Тест заключается в следующем: * запрос к бд * вернуть результат То есть, ни авторизаций, ничего прочего. Просто sql запрос и вывод строки. Результаты следующие: на 1000 запросов php7 справился быстрее на 30%. Как такое может быть ? Пробовали в go держать одно соединение с базой - результат не изменился.

Трешак, бенчмарки, которые мы заслужили

Если локально, то вообще unix socket скорее всего

сокеты бывают 2-х типов (стрим=TCP, датаграм=UDP)

сокеты бывают 2-х типов (стрим=TCP, датаграм=UDP)

экономия на транспорте может достигать x5

Даже пришлось гуглить, там не TCP или UDP

Даже пришлось гуглить, там не TCP или UDP

MySQLoverIP?

Даже пришлось гуглить, там не TCP или UDP

Ethernet->IP->?????

MySQLoverIP?

С локальной базой, если указать localhost, используется /var/lib/mysql/mysql.sock

сокеты бывают 2-х типов (стрим=TCP, датаграм=UDP)

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BA%D0%B5%D1%82_%D0%B4%D0%BE%D0%BC%D0%B5%D0%BD%D0%B0_UNIX

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BA%D0%B5%D1%82_%D0%B4%D0%BE%D0%BC%D0%B5%D0%BD%D0%B0_UNIX

запутали .... дак это вообще не сеть а обмен через память(ну заменили Ethernet памятью... а дальше все тоже самое) ! 8))))))) ... Читайте дальше а не только заголовок , даный вид сокетов делится на Stream=TCP и Datagram=UDP