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

Чет это совсем дебри :)

ок, понял спасибо

а как тогда сделать запись в канал асинхронную и при этом выйти из функции?? go func(req *web.Request) { g.Lock() defer g.Unlock() g.buffered_data <- *req // вот тут падает в panic }(req) заменил на просто g.buffered_data <- *req // вот тут падает в panic и оно подвисло на записи в канал с выходом из теста с exit code = 2

Зачем нужна асинхронная запись в канал?

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

Почитай про буферизованные каналы

Короткий ответ - если буфер НЕ переполнен, не подвисает

ну я прочитал видимо ничего не понял, или понял как то не так ОК я сделал буфферизированый канал и убрал горутину с замыканием и оно теперь вообще бенчмарк не запускает а выходит с exit code=2 ;)

ну я прочитал видимо ничего не понял, или понял как то не так ОК я сделал буфферизированый канал и убрал горутину с замыканием и оно теперь вообще бенчмарк не запускает а выходит с exit code=2 ;)

А как ты создаёшь глобмальную структуру g?

func NewGA2ClickHouse() GA2ClickHouse { return GA2ClickHouse{ schema_version: 1, form_k_exists_map: make(map[string]bool), db_field_list: make([]string, 0), db_field_map: make(map[string]int), db_to_form_map: make(map[string]string), nested_tables: make(map[string]NestedTable), buffered_data: make(chan web.Request, 100), } } func prepareCollectorToBenchmark() GA2ClickHouse { g := NewGA2ClickHouse() g.drop_database = true g.chunk_size = 100 g.data_dir = "./data" g.geoip_dir = "./geoip" g.database = "ga2clickhouse_test" g.cluster_name = "ga2clickhouse_test" g.table_prefix = "" g.clickhouse_hosts = []string{"local.ga2clickhouse.clickhouse.pro:8123"} g.CreateDataDir() g.InitGeoip() g.InitBrowseCap() g.InitClickHouseClient() g.CreateClickHouseTables() go g.ProcessRequest() return g } // дальше в бенчмарке func BenchmarkGA2ClickHouse_CollectSequenced(b *testing.B) { g := prepareCollectorToBenchmark() //defer g.ShutdownCollector() убрал чтобы не закрывать канал раньше log.Printf("b.N=%d", b.N) b.ResetTimer() for i := 0; i < b.N; i++ { req := NewTestRequest() rw := web.ResponseWriter(testResponseWriter{}) g.Collect(rw, &req) } }

блин у меня такое ощущение что у меня горутина которая данные принимает не успевает из канала прочитать к тому моменту когда бенчмарк функция выходит b.N=1

но по идее пока g.ProcessRequest не отработает g не должен быть убить через GC ??? такведь??

блин у меня такое ощущение что у меня горутина которая данные принимает не успевает из канала прочитать к тому моменту когда бенчмарк функция выходит b.N=1

скорее всего - не успевает

но почему должна?

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

а как это сделать???

Ну простейший вариант waitgroup. В твой код не вдавался, т.ч. не обязательно, что этот способ синхронизации каналов подойдет в твоем кейсе

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

вот да, потому что Add(int) а не Add(func)

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

а как правильно то? ;)

Ну, как я понимаю горутин "принимающие даные" много в его кейсе, а отправляющаю\ждущая обработки - одна. И как раз таки поставив wg.Wait можно дождаться завершения этих "обрабатывающих" горутин и продолжить работы

нет горутина принимающая данные ОДНА

но она не успевает прочитать из буферизированного канала потому что функция бенчмарка, просто выходит раньше при b.N и GC убивает и горутину и канал?

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

или тоже не подходит?

выглядит как окстыль... мне так то надо забенчмаркать как много Collect смогут писать в одну ProcessRequest а она в свою очередь должна писать в TSV файл

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

а как все таки правильно дождаться всех запущенные горутины? waitGroup ?

да, именно так

перед запуском рутины делаешь Add

выглядит как окстыль... мне так то надо забенчмаркать как много Collect смогут писать в одну ProcessRequest а она в свою очередь должна писать в TSV файл

это очевидно скорость записи в файл

после тог, как она отработала Done. и в конце блока, где надо пождать пишешь Wait

https://nathanleclaire.com/blog/2014/02/15/how-to-wait-for-all-goroutines-to-finish-executing-before-continuing/ - вот с примерами

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

но с WaitGroup код нормальный

спасибо за ссылку

спасибо за ссылку

ссылка не поможе :(

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

а я не знал что можно делать range по каналу какой интерфейс должна реализовывать сущность чтобы по ней можно было делать range ?

по-моему только по slice, map, channel можно range делать

https://golang.org/ref/spec#RangeClause

а я не знал что можно делать range по каналу какой интерфейс должна реализовывать сущность чтобы по ней можно было делать range ?

никакой

а как правильнее делать ? for { select } или

for i := range channel ?

смотря сколько у тебя каналов

которые ты хочешь слушать

я обысно использую 2 минимум

1 - данные, 2 управляющий

поэтому for {select case}

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

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

https://blog.golang.org/pipelines - Тут несколько неплохих примеров есть, чтоб далеко не ходить

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

+ удобно иметь таймер ожидания, это еще один канал

for i := range channel можно просто закрыть канал

а как правильнее делать ? for { select } или

select нужен в двух случаях 1. ты хочешь читать более одного канала 2. ты хочешь неблокирующегося ввода-вывода из/в канал(а)

неблокирующийся, как ни странно, иногда нужен

более одного канала - это очень специфический случай

более одного канала - это очень специфический случай

Обычно второй канал или управляющий или таймер

Еще одно, из for d := range ch можно выйти только по закрытию канала из другой горутины

Ещё по break

Ещё по break

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

более одного канала - это очень специфический случай

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

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

и, тем не менее, это очень специфический случай

и, тем не менее, это очень специфический случай

использовать более одного канала это плохо? (

нет, это нормально.

просто это, действительно, специфика - отдельный канал под управление/таймер/whatever

обычно остаточно закрытия канала для сигналинга

что-то я савсем запутался вот сделал я канал буферизированный (размер буферв 100) скажите, пока буффер не заполнится select в горутине читателе не вызовется?? так ведь?

нет :)

не так

а как?

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

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

я не про запись... я про чтение... чтение когда вызывается?

операция чтения блокируется во всех случаях когда пусто

а если не пусто??? то когда?

операция записи когда буфера нет или он полон

операция чтения блокируется во всех случаях когда пусто

внутри селекта с секцией defaul - не блокируется

то никогда. вопрос непонятен