ааа... ну это в доке с примернами... ок. wg.Done внутри замыкания... понял спасибо =)

имеется в виду var wg sync.WaitGroup for ... { wg.Add(1) go func() { ... wg.Done() }() } wg.Wait()

+1

извините, отвлекся

Но мне, если честно, больше понравилось с фьючами

нет вот этого вот хардкора с подсчётом

фьючи? в го?

фьючи? в го?

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

var futures []chan TestResult for _, test := range tests { c := make(chan TestResult) go func(t TestFile) { result, err := t.Run() if err != nil { log.Println(err) } c <-result }(test) futures = append(futures, c) } var results []TestResult for _, c := range futures { results = append(results, <-c) }

вот

это такая себе фьюча, конечно

но суть примерно та же

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

Вообще-то, это не совсем future. Future может подождать много goroutine, а значение из канала можно прочитать только один раз.

Future можно реализовать или через WaitGroup, или путём закрытия канала

т.е. значение в сторонке, а броадкаст или через close(chan), или через wg.Done()

ага, понял

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

Скажите, я один не понимаю зачем?

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

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

Waitgroup

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

подождать не проблема, хоть с ним, хоть без

Не, я понимаю зачем это, я не понимаю, зачем фьючи

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

и потом банальный for-loop'ом одновременно жду и получаю результаты

меньше кода

А что ещё важнее — меньше стейта

я тут изо всех сил смиряю плоть и пытаюсь полюбить Го

после кложи и скалы это непросто

О, разу уж тут

А не появилось ли случайно дебаггера отличного от GDB обвешенного скриптами?

ну dlv вроде как в golangd встроенный идет https://github.com/derekparker/delve и даже работает

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

Зачем ? Можно принимать по одному каналу результаты и писать их куда надо (или что нужно с ними делать?)

можно, но в таком случае надо заранее знать длину буфера канала

а это опять лишний стейт

я же не могу со стороны последней горутины сделать close(c)

я не знаю когда она там будет

ну dlv вроде как в golangd встроенный идет https://github.com/derekparker/delve и даже работает

спасибоньки

А не появилось ли случайно дебаггера отличного от GDB обвешенного скриптами?

https://github.com/aarzilli/gdlv

я же не могу со стороны последней горутины сделать close(c)

Дык это надо делать на принимающей стороне

можно, но в таком случае надо заранее знать длину буфера канала

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

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

ну вот такая у меня привычка, как у функциональщика со стажем

Ты лучше скажи, чем плохая идея с "фьючами"?

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

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

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

ну вообще говоря нет

results = append(results, <-c)

var futures []chan TestResult for _, test := range tests { c := make(chan TestResult) go func(t TestFile) { result, err := t.Run() if err != nil { log.Println(err) } c <-result }(test) futures = append(futures, c) } var results []TestResult for _, c := range futures { results = append(results, <-c) }

собсно вот результирующий код

он ничего не знает о размерах или количестве

Ты лучше скажи, чем плохая идея с "фьючами"?

На самом деле, конечно же, она не так плоха, как можно подумать, просто зачем например создавать много каналов, если можно один?

ну вот меня этот вопрос тоже парит

results = append(results, <-c)

Ты таким образом получишь много аллокаций вместо одной

Ты таким образом получишь много аллокаций вместо одной

я к этому привык :)

но да, в принципе засчитано

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

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

Дешёвая, да не очень

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

Дешёвая, да не очень

И довольно медленная, надо сказать

это да, но не на тех объёмах

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

это да, но не на тех объёмах

Ну, если у тебя там горутин сто, то конечно беспокоится нечего

мне кажется байтоёбством заниматься на 30 воркерах особого смысла нет

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

А, ну тем более

Просто, имхо, зачем делать как не надо, если можно сделать как надо?

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

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

мне ещё предстоит полюбить стейт, have mercy

пока он меня пугает больше, чем лишние аллокации

ERROR: S client not available

мне ещё предстоит полюбить стейт, have mercy

В го тебе придётся работать со стейтом, это не скалка и не хускель :3

ну вот же

это сложно :3

надо мозг

а у меня нет

Ты ещё видимо с context не сталкивался, вот где весь ужос :3

Пока нет

Советую ознакомиться, полезная и нужная штука

спасибоньки, гляну

https://golang.org/pkg/context/

http://telegra.ph/Go-Newsletter-Issue-144-January-26-2017-01-26

Товарищи, подскажите пожалуйста

func main() { naturals := make(chan int) squares := make(chan int) // Counter go func() { for x := 0; x < 100; x++ { naturals <- x } close(naturals) }() // Squarer go func() { for x := range naturals { squares <- x * x } close(squares) }() // Printer (in main goroutine) for x := range squares { fmt.Println(x) } }

вот есть код, горутины с каналами

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

правильно я понимаю?

вроде как не правильно

хм....

или как бы устроено следующим образом

а с чего он последовательно выполняется

есть горутина1, которая запихивает в канал1 циферьки

и парралельно с ней крутится другая горутина, которая слушает канал1 и только когда в канал1 приходят данные она отрабатывает

так правильнее?

ну. так в чем не параллельность? или даже так - а как должна выглядеть параллельность, чтобы сказать: "Вот она!"

не не, неправильности никакой нет. я пытаюсь понять

разобраться

Строго говоря, в Го не параллельности. есть конкурентное программирование

смотрю как работают разные проги, экспериментирую и строю гипотезы )

А чего строить гипотезы, если вроде как всё ясно описано. "Распараллеливание" сопрограмм через "go чтото". Шедулинг по i/o. Общение через каналы. Всё

ну, это вам всё понятно ? а мне после php не особо понятно

Общение в том числе используется как передача и прием управления за счет шедулинга по i/o