короче заблокировали всё, но телега работает... о боже...

Здравствуйте! Можете помочь?

задавай вопрос, не стисняйся)

не окончательно пока

Вы просто опытный разработчик

у меня тг тоже лагает

задавай вопрос, не стисняйся)

Как правильно слайс структур вытаскивать из горутин?

Пока вот так, я думаю они по домам пошли, с утра опять начнётся.

Как правильно слайс структур вытаскивать из горутин?

пардон?.. не понял вопрос честно говоря) больше подробностей

Сейчас делаю так в цикле v, ok := <- chStructs if ok { products = append(structs, v...) } else { break }

п*здец, еб@нулись на всю голову

пардон?.. не понял вопрос честно говоря) больше подробностей

Пытаюсь многопоточно парсить данные с api

Пытаюсь многопоточно парсить данные с api

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

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

типо того GET запросами

типо того GET запросами

рутины сами делают запросы?

да

честно говоря я представляю себе решение легче с mutex'ом нежели каналом

написать структуру с методом Add(result) которая защищает некий слайс результатов мьютексом

при завершении обработки запроса worker горутина просто вызывает этот метод

type Results struct { results []string lock sync.RWMutex } func NewResults() *Results { return &Results{ results: make([]string, 0), lock: sync.RWMutex{}, } } func (res *Results) Add(newResult string) { res.lock.Lock() res.results = append(res.results, newResult) res.lock.Unlock() } // Returns all accumulated results and empties the buffer func (res *Results) Flush() []string { res.lock.RLock() defer res.lock.RUnlock() return res.results } func worker(results *Results) { // http.Get(...) results.Add("newResult") } func aggregator(results *Results) { for _ := range results.Flush() { // process } } func main() { results := NewResults() for i := 0; i < 16; i++ { go worker(results) } go aggregator(results) }

что-то в этом роде

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

isTrainerReserved(trainerId, beginTime, endTime)

вот есть у нас тренер, у него могут быть appointment'ы с клиентами. У каждого appointment'а есть время начала и время конца. Какая структура лучше справится с подобной задачей?

очередь ? мимопроходил

type Results struct { results []string lock sync.RWMutex } func NewResults() *Results { return &Results{ results: make([]string, 0), lock: sync.RWMutex{}, } } func (res *Results) Add(newResult string) { res.lock.Lock() res.results = append(res.results, newResult) res.lock.Unlock() } // Returns all accumulated results and empties the buffer func (res *Results) Flush() []string { res.lock.RLock() defer res.lock.RUnlock() return res.results } func worker(results *Results) { // http.Get(...) results.Add("newResult") } func aggregator(results *Results) { for _ := range results.Flush() { // process } } func main() { results := NewResults() for i := 0; i < 16; i++ { go worker(results) } go aggregator(results) }

такой подход в том или ином виде почти на любом ЯП можно сделать, интересно, как оптимальнее и правильнее в Go?

такой подход в том или ином виде почти на любом ЯП можно сделать, интересно, как оптимальнее и правильнее в Go?

а чем сия конструкция неправильна?) да, в Go есть каналы, но они не всегда лучше старых добрых mutex'ов))

а чем сия конструкция неправильна?) да, в Go есть каналы, но они не всегда лучше старых добрых mutex'ов))

у меня недостаточно опыта в Go, чтобы делать выводы. зачем вообще каналы, если есть мьютексы?

у меня недостаточно опыта в Go, чтобы делать выводы. зачем вообще каналы, если есть мьютексы?

каналы зачастую легче читаются, но не в каждом случае. по сути каналы можно ассоциировать с трубами. Канал это труба в которую гофер (горутина) может что-то положить или из неё что-то взять.

это способ безопасной коммуникации гоферов)) т.е. горутин

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

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

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

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

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

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

это 2 разные парадигмы, каналы = communication, мьютекс = shared mutable state. Для разных проблем разные инструменты

это 2 разные парадигмы, каналы = communication, мьютекс = shared mutable state. Для разных проблем разные инструменты

допустим, вам нужно делать проверку на дубликаты перед запросом, чтобы не делать лишнюю работу. нужен еще 1 лок?

Ну канал это тоже мютексты мютексы.

Ну канал это тоже мютексты мютексы.

канал это примитива коммуникации, которая внутри своей имплементации использует мьютекс, ибо коммуникация это абстракция над shared state'ом

допустим, вам нужно делать проверку на дубликаты перед запросом, чтобы не делать лишнюю работу. нужен еще 1 лок?

не понял вопрос чес гря

Если есть поток данных, то каналы, если общее хранилище, то мютексты или атомики.

канал это примитива коммуникации, которая внутри своей имплементации использует мьютекс, ибо коммуникация это абстракция над shared state'ом

Ну поэтому тут думать о том что использовать как то и не возникает вопросов.

Ну поэтому тут думать о том что использовать как то и не возникает вопросов.

как я уже сказал - каналы подходят только для коммуникации, если речь идёт о shared state'е то зачастую удобнее работать atomic'ами и mutex'ами

не понял вопрос чес гря

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

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

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

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

предположим, это невозможно, потому что они читаются из потока и их 1 миллиард

предположим, это невозможно, потому что они читаются из потока и их 1 миллиард

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

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

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

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

в чём проблема? добавляешь метод Reset(url) который вызывается в случае ошибки и норм)

в чём проблема? добавляешь метод Reset(url) который вызывается в случае ошибки и норм)

еще мьютекс. и логика, сколько уже методов в вашей структуре на данный момент? 8 и 3 мьютекса?

еще мьютекс. и логика, сколько уже методов в вашей структуре на данный момент? 8 и 3 мьютекса?

2 метода и 1 мьютекс

2 метода и 1 мьютекс

мы же добавили IsNew и Reset как минимум

в каждом из них по мьютексу

или вы хотите все блочить 1 мьютексом?

предполагаю что IsNew и Reset не пришли одни и еще притащили с собой методов для обработки чего нибудь внутри структуры. ведь теперь еще есть "таймер" который через минуту запустит Урл с ошибкой еще раз

еще мьютекс. и логика, сколько уже методов в вашей структуре на данный момент? 8 и 3 мьютекса?

type UrlRegistry struct { urls map[string]struct{} lock sync.Mutex } func NewUrlRegistry() *UrlRegistry { return &UrlRegistry{ make(map[string]struct{}) sync.Mutex{}, } } // IsNew returns true if the given url was already checked, otherwise returns false and immediately registers the new url func (reg *UrlRegistry) IsNew(url string) bool { reg.lock.Lock() defer reg.lock.Unlock() if _, exists := reg.urls; !exists { req.urls[url] = struct{} return false } return true } // Reset removes the given url from the registry func (reg *UrlRegistry) Reset(url string) { reg.lock.Lock() req.lock.Unlock() delete(reg.urls, url) }

понимаете, чем плохо лочить все приложение 1 мьютексом?

понимаете, чем плохо лочить все приложение 1 мьютексом?

а вы понимаете что лочить один мап двумя мьютексами убивает смысл мьютексов создавая опасность data race'а?

мьютекс это примитив синхронизации... если мы делим один мап меж несколькими потоками то их надо синхронизировать

а вы понимаете что лочить один мап двумя мьютексами убивает смысл мьютексов создавая опасность data race'а?

да! представим, что это приложение написано на каналах

да! представим, что это приложение написано на каналах

ну и как ты это напишешь на каналах?

плюс на каналах будет скорее всего медленее

плюс на каналах будет скорее всего медленее

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

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

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

ну и как ты это напишешь на каналах?

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

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

и чем это отличается от примера со структурой?

и чем это отличается от примера со структурой?

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

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

напиши пример если не лень, который решает ту проблему только на каналах ?

ERROR: S client not available

напиши пример если не лень, который решает ту проблему только на каналах ?

вчера решал задачку в go tour https://play.golang.org/p/r_1qWx17Qd8

вчера решал задачку в go tour https://play.golang.org/p/r_1qWx17Qd8

так, постой, у тебя же Cache почти то-же самое что у меня тот пример выше?!

type UrlRegistry struct { urls map[string]struct{} lock sync.Mutex } func NewUrlRegistry() *UrlRegistry { return &UrlRegistry{ make(map[string]struct{}) sync.Mutex{}, } } // IsNew returns true if the given url was already checked, otherwise returns false and immediately registers the new url func (reg *UrlRegistry) IsNew(url string) bool { reg.lock.Lock() defer reg.lock.Unlock() if _, exists := reg.urls; !exists { req.urls[url] = struct{} return false } return true } // Reset removes the given url from the registry func (reg *UrlRegistry) Reset(url string) { reg.lock.Lock() req.lock.Unlock() delete(reg.urls, url) }

^

так, постой, у тебя же Cache почти то-же самое что у меня тот пример выше?!

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

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

ну так это 1 в 1 тоже самое что и я написал

ну так это 1 в 1 тоже самое что и я написал

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

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

Roman https://play.golang.org/p/Dw4rc0gEdFp

переместил логику cache'а в сам кэш, а наружу удобный API, ибо иначе нарушается принцип энкапсуляции

Roman https://play.golang.org/p/Dw4rc0gEdFp

да, так лучше

кстати "регистр" более правильное название нежели кэш, кэш это про другое совсем)

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

твоя структура cache это 1 в 1 мой пример сверху, в ней ничего не отличается

ты так-же лочишь при чтении visited перед каждым запросом

ты так-же лочишь при чтении visited перед каждым запросом

но не лочу для записи. и для всех последующих возможных действий над регистром

но не лочу для записи. и для всех последующих возможных действий над регистром

здрасьте, это как это не лочишь для записи, а в Visited тогда что происходит?

здрасьте, это как это не лочишь для записи, а в Visited тогда что происходит?

1 лок нужен, лок перед записью - нет

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

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

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

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

в решение с 1 мьютексом могут возникнуть ситуации, когда сотни горутин ожидают лока

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

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

в решение с 1 мьютексом могут возникнуть ситуации, когда сотни горутин ожидают лока

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

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

он же "глобальный" - передается по указателю

он же "глобальный" - передается по указателю

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

в конкурентном программировании либо shared state который нужно синхронить в контексте всех потоков, либо локальные копии в стэках потоков

в конкурентном программировании либо shared state который нужно синхронить в контексте всех потоков, либо локальные копии в стэках потоков

считай, это shared state

тогда ничем в данном случае канал не лучше

это такой-же мьютекс

Все спят?

Все спят?

не могут в телеграм зайти

Не надо было выходить.

Шлялся всю ночь где-то, теперь удивляется, что домой не пускают.