Про последние три строчки

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

Я думаю тебе подойдёт что-то типа https://github.com/ninedraft/limiter

Про последние три строчки

Ок, посмотрю wg, че то я про него и не подумал даже

Я думаю тебе подойдёт что-то типа https://github.com/ninedraft/limiter

Спасиб

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

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

Нет, я все ответы в канал сунул

results <- fmt.Sprintf("Thread %d: %v\n", thread, err)

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

Вот когда ставлю ограниченно кол-во воркеров, например три

Она возвращает 3 результата и на этом просто стоит прога

Ничего не делая, при этом не выходит

for w := 0; w < len(hosts); w++ тут я имею ввиду

Аа, ну правильно!

Объясни, пожалуйста, с чем связано, я хоть пойму)

Горутина же не читает из канала циклически

Каждая обрабатывает только одну задачу

то есть если я это упакую в for{}, то сработает?

Погоди, гляну доку на x/ssh

Не над

Хм, а что за пакет такой вообще? Есть x/crypto/ssh

Я руками сам

Без пакета

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

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

Тогда покажи, что делает 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. Но так как он читает задачи из канала, то всё в целом правильно.

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

и беспощадно

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

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

Почему нет?

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

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

Почему нет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто использует fasthttp вместо net/http? Какие минусы кроме поддержки http2? Чистый или с каким-то микрофреймворком?

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

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

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

Но я хочу сделать не 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) } }