Он не подходит мне

Тогда покажи, что делает ssh.Scan

Да перезагрузка комп, повесил случайно

close(jobs) никогда не выполнится

Канал буферизированный - все задачи влезут.

package ssh import ( "fmt" "net" "time" ) func Scan(thread int, jobs <-chan string, results chan<- string) { for j := range jobs { _, err := net.DialTimeout("tcp", j+":22", 5*time.Second) if err != nil { results <- fmt.Sprintf("Thread %d: %v\n", thread, err) return } results <- fmt.Sprintf("Thread %d: %s port is opened.\n", thread, j) } }

Это вот сама функция scan

https://play.golang.org/p/GmCueoKFXIj

всё работает как надо

То есть этот код можно считать хорошим?

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

Да, я сначала не понял, как именно работает ssh.Scan. Но так как он читает задачи из канала, то всё в целом правильно.

Я бы только не стал делать канал с таким буфером - это бессмысленно

и беспощадно

Простой небуфиризированный сделать?

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

Почему нет?

но когда хочется и колится, то можно

Да. Только читающую горутину запусти _сначала_

Почему нет?

Ну я пока не силен в го, вот и решил уточнить) По верному пути ли я иду

Да. Только читающую горутину запусти _сначала_

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

Ну я пока не силен в го, вот и решил уточнить) По верному пути ли я иду

Можно много горутин 👌

Можно много горутин 👌

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

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

Ой, я не прочитал о чём шла речь 😅

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

Ну вот я и хотел ограничить кол-вом воркеров это дело

Это правильно, да.

Я думал у вас миллион коннектов

Всем спасибо, очень помогли) А то сижу со вчера и думаю как реализовать)

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

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

Работаю, над этим)

А так по честному, не очень у меня на го? Да?

Я просто до этого на питоне бацал

у всех не очень и все живут

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

у фастхттп были юзкейсы кмк

подходит для задач - используй

не подоходит - не используй

Но я хочу сделать не 254 воркера(w := 0; w < len(hosts); w++), а всего 10

А зачем WorkerGroup когда есть семафоры с помощью которых всегда ограничивались количество одновременно живущих потока? http://jmoiron.net/blog/limiting-concurrency-in-go

А wg на самом деле не очень подходит пока что, сейчас буду думать

Почитаю, посмотрим) Если интересно будет потом могу отписать, как решил это

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

воркеры с манагером общаются аля Task & TaskResult сообщениями

А зачем WorkerGroup когда есть семафоры с помощью которых всегда ограничивались количество одновременно живущих потока? http://jmoiron.net/blog/limiting-concurrency-in-go

Кстати изначально я так и думал сделать типа канал done

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

как наваяешь, лучше код покажи

кто нить да подскажет

Ну да, наверное так и сделаю, но пока проблем нет вроде

WaitGroup (да, я ошибся, когда назвал их WorkerGroup) нужен чтобы не отслеживать количество результатов, а просто дождаться пока все горутины отработают. Вот пример - https://golang.org/pkg/sync/#example_WaitGroup

Это классическая задача решается или через семафоры или через thread pool. По крайней мере в оствльных языках

Это классическая задача решается или через семафоры или через thread pool. По крайней мере в оствльных языках

Ну вот у меня и есть thread pool

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

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

Это как ты имеешь ввиду? Кинь примерчик какой нить

Вот с записью в отдельной горутине и канал без буфера - https://play.golang.org/p/E725utf5Et_X

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

Главное - чтобы и запись и чтение работали одновременно

Хм

Ща попробую

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

Или я ошибаюсь?

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

Так же?

Я может быть не так что - то понимаю

в мейне создаю несколько воркеров

WaitGroup тут пока не нужен, т.к. всё еще есть подсчет задач. А смысл изменения - убрать буфер у канала и сохранить немного памяти (ну или много)

а... оптимизируете)

А, понял. Просто еще с объемами данных такими не успел столкнуться, надо бы попробовать поигратьсья с огромным кол-вом данных

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

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

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

А, понял. Просто еще с объемами данных такими не успел столкнуться, надо бы попробовать поигратьсья с огромным кол-вом данных

объёмные данные тоже интересный вопрос большие задачи можно побить на поменьше и при этом оставить буфер, если он нужен

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

да

да

Ну так тоже можно, да. Только WaitGroup же сделан именно для этого.

Ну так тоже можно, да. Только WaitGroup же сделан именно для этого.

у меня там логика была по сложнее

объёмные данные тоже интересный вопрос большие задачи можно побить на поменьше и при этом оставить буфер, если он нужен

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

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

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

Я вот как переделал сейчас

package main import ( "flag" "fmt" "log" "sync" "x/ssh" ) func main() { var wg sync.WaitGroup pool := flag.String("p", "", "IP format 192.168.1.0/24") flag.Parse() // 64.254.32.0/24 hosts, err := ssh.GenerateHosts(*pool) if err != nil { log.Fatalf("[ERROR] %v\n", err) } results := make(chan string, 5) for _, host := range hosts { wg.Add(1) go func(host string) { wg.Done() ssh.Scan(host, results) }(host) } wg.Wait() for i := 0; i < len(hosts); i++ { fmt.Print(<-results) } }

jobs убрал за ненадобностью

а чего результаты аж на 5?

А да это еще не трогал)

я вот кстати не до конца еще буффер понимаю у канадов

wg.Done() ssh.Scan(host, results) done после Scan?

ой